VHDL Issue Number:      0109
Classification:         Language Definition Problem
Language Version:       VHDL-87
Summary:                Can type information be used to disambiguate names?
Related Issues:         0006, 0047, 0108
Relevant LRM Sections:  2.3, 7.3.3, 10.5
Key Words and Phrases:  Subprogram overloading, Overload resolution,
                        Function calls
Current Status:         Analyzed
1076-1993 Disposition:  Closed (All Issues Completely Addressed)
Disposition Rationale:  LRM was updated.
Superseded By:          N/A
-----------------------
Date Submitted:         1988/06/06
Author of Submission:   Jim Reed
Author's Affiliation:   CAD Language Systems, Inc.
Author's Post Address:  P.O. Box 13036
                        Research Triangle Park, NC  27709-3036
Author's Phone Number:  (919) 361-1913
Author's Fax Number:    
Author's Net Address:   jimr@clsi.com
-----------------------
Date Analyzed:          1991/01/18
Author of Analysis:     Paul Menchini (mench@clsi.com)
Revision Number:        $Revision: 1.10 $
Date Last Revised:      $Date: 1995/08/03 18:30:18 $


Description of Problem
----------------------
It is unclear whether type information can be used to disambiguate names.
Consider the following example:

        :
        :
      type A is array (1 to 10) of integer;
      function AF (P : integer := 3) return A;
      variable I : integer;
    begin
      I := AF (3);      -- identical to either AF (P => 3) or AF (P => 3) (3)
        :
        :

The expression AF(3) has two interpretations: the array returned from AF when
it is called with the argument 3, or the third element in the array returned
from AF when the default value is used for its parameter.  Type information
can be used to determine that the second alternative is correct.  However, the
LRM makes no statement on whether or not using type information is allowed
here.

Using type information as described in both examples is different from overload
resolution.  The type information is not used to select one function from
several alternatives, but to determine whether or not a function call is
intended (in the first example) or to determine whether or not to use the
default values for parameters in a specific function call.


Proposed Resolution
-------------------
Allow type information to be used to disambiguate names when needed.


VASG-ISAC Analysis & Rationale
------------------------------
This issue was considered together with issues 6, 47, and 108.  These other
issues concern selected and expanded names, while this issue deals with a
function call, so it is analyzed and resolved separately.

By applying VHDL's visibility rules, it is clear that the example name is a
function call; moreover, there is no doubt as to which function, since the
function is not overloaded.  What is not clear is whether the parameter to the
function is defaulted or explicitly specified.  The final paragraph of Section
2.3 is of no assistance, since it specifies what information can be used to
identify which subprogram is being invoked.

Section 7.3.3 also does not specify whether or not type information can be used
to determine whether the parameters are defaulted.

However, rule 1 of paragraph 4 in Section 10.5 allows the use of type
information in determining the interpretation of a complete context
encompassing a name.  Thus, there seems to be weak support for allowing type
information to disambiguate the example name.

Therefore, the author's recommendation is accepted.

(It is interesting to note that Ada doesn't seem to have resolved this
problem.)


VASG-ISAC Recommendation for IEEE Std 1076-1987
-----------------------------------------------
Allow type information to be used to disambiguate the parameter association
lists of subprogram calls.


VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
Encorporate explicit support for this conclusion in either Section 2.3 or 10.5.