VHDL Issue Number:      0108
Classification:         Language Definition Problem
Language Version:       VHDL-87
Summary:                Can type information be used to disambiguate names?
Related Issues:         0006, 0047, 0109
Relevant LRM Sections:  2.3, 6.3, 10.5
Key Words and Phrases:  Subprogram overloading, Overload resolution,
                        Selected names, Expanded names
Current Status:         Closed (Andy Tsay)
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.11 $
Date Last Revised:      $Date: 1995/08/03 18:30:03 $


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

        type R is
          record
            A : bit;
          end record;

        function F return R is
          variable A :  integer;
          variable B :  bit;
        begin
          for A in 1 to 10 loop
            B := F.A;           -- either variable A or element A
          end loop;
        end F;

F.A has two interpretations:  the variable A declared in function F or the
element A of the return value of a recursive call to F.  This is only an issue
within the body of F, in all other cases the second meaning is the only one
possible.

If type information can be used, it is easy to determine that record element A
is the correct interpretation.  However, if the variable and the record element
were of the same type, the ambiguity would not be resolvable with type
information.

The LRM is not clear on whether or not type information can be used to
determine which interpretation is correct.  It assumes that the prefix will
always be unambiguous.  However, in this example, the prefix F can denote
either a record value or the function's declarative part.


Proposed Resolution
-------------------
Adopt the Ada interpretation: a selected name whose prefix denotes a function,
when used within the function named by the prefix, always denotes an object in
the function's declarative part.  (Note that this is only an issue when the
function may be called without arguments.)

Note that if this resolution is adopted, it is not necessary to use type
information to disambiguate names in this case.  However, there may be cases
where this disambiguation is still necessary (see issue 0109).


VASG-ISAC Analysis & Rationale
------------------------------
This issue was considered together with issues 6, 47, and 109.  The analysis,
rationale, 1987 recommendation and future recommendation sections of Issue 6
apply equally to this issue.


VASG-ISAC Recommendation for IEEE Std 1076-1987
-----------------------------------------------
See Issue Report 0006.


VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
LRM revised in IEEE Std 1076-1993 in LRM 6.3.
Issue closed.