VHDL Issue Number:      0245
Classification:         Language Definition Problem
Language Version:       VHDL-87
Summary:                Direct visibility rules for USE clauses are incomplete
                        and confusing.
Related Issues:         IR0198
Relevant LRM Sections:  10.4
Key Words and Phrases:  use clause, direct visibility,
                        potentially visible declaration
Current Status:         Submitted
1076-1993 Disposition:  Superseded (ISAC Issues Outstanding)
Disposition Rationale:  N/A
Superseded By:          1051
-----------------------
Date Submitted:         1991/10/11
Author of Submission:   Chuck Swart
Author's Affiliation:   Mentor Graphics Corporation
Author's Post Address:  8005 S.W. Boeckman Road
                        Wilsonville, OR 97070-7777
Author's Phone Number:  (503) 685-7000
Author's Fax Number:    
Author's Net Address:   chuck_swart@mentorg.com
-----------------------
Date Analyzed:          TBD
Author of Analysis:     TBD
Revision Number:        $Revision: 1.10 $
Date Last Revised:      $Date: 1995/05/13 21:53:48 $


Description of Problem
----------------------
(1) Consider the following VHDL code:


    PACKAGE p1 IS
        FUNCTION foo RETURN bit;
    END p1;

    PACKAGE p2 IS
        FUNCTION foo RETURN bit;
    END p2;

    PACKAGE p3 IS
        USE work.p1.all;
        USE work.p2.all;
        CONSTANT c1:bit := foo;
    END p3;

Is this legal VHDL code? Most implementations say no, that
foo is not visible. The LRM does not say that foo is not
visible, nor does it indicate which foo is visible.

The applicable LRM paragraph is from section 10.5 which reads in part:

"A potentially visible declaration is actually made directly visible except in
the following (case):...

Potentially visible declarations that have the same designator are not made
directly visible unless each of them is either an enumeration literal
specification or the declaration of a subprogram (either by a subprogram
declaration or by an implicit declaration)."

(2a) Next, consider the following VHDL code:

    PACKAGE p1 IS
        TYPE t1 IS (a,b,c);
    END p1;

    PACKAGE p2 IS
        TYPE t1 IS (d,e,f);
    END p2;

    PACKAGE p3 IS
        USE work.p1.all;
        USE work.p2.all;
        CONSTANT c1:boolean := a = b;
    END p3;

This code is legal VHDL.
It has the unintuitive property that although neither type T is directly
visible, all of the standard predefined operators on these types are directly
visible, as are the corresponding enumeration literals.

(2b) As a companion problem, if you "use" a type T, then T
becomes visible, but none of the predefined standard operators for T are
visible.

(3) Suppose that you want to overload the standard relational operators
on bit vectors. For example, you might want to use numeric comparisons
instead of arithmetic comparisons. An obvious way to do this is to define
the overloaded operators in a package. However, if a VHDL program
USEs this package in the context clause of a design unit, then neither
the overloaded operators, nor the standard operators are directly visible
within the design unit. This behavior is unintuitive and undesirable.
However, if you USE the same package within a block, the overloaded
operators become visible. Again, this is very confusing to the typical
user.


Proposed Resolution
-------------------
For case (1) The appropriate paragraph should include a sentence such as:
"Two potentially visible declarations are not made directly visible if
they are homographs."

For case (2) one view of the problem is that there is inadequate
association between a type and its operators.

Case (3) arises apparently from the desire to not have textual order
play a role in direct visibility of use clauses, so that:

    USE work.p1.all;
    USE work.p2.all;

is equivalent to

    USE work.p2.all;
    USE work.p1.all;

In my opinion, this rule results in overly conservative restrictions
on direct visibility which are far worse than the problem it was designed
to solve.


VASG-ISAC Analysis & Rationale
------------------------------
TBD


VASG-ISAC Recommendation for IEEE Std 1076-1987
-----------------------------------------------
TBD


VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
TBD