-------------BEGINNING OF IR---------------- VHDL Issue Number: 2058 Language_Version VHDL-93 Classification Language Definition Problem Summary does USE of type name make operators and literals visible? Relevant_LRM_Sections 10.4 USE clauses, line 217 10.3 Visibility, line 150 Related_Issues Key_Words_and_Phrases Authors_Name James Authors_Phone_Number 503-685-0860 Authors_Fax_Number Authors_Email_Address jamesu@model.com Authors_Affiliation Model Technology Authors_Address1 Authors_Address2 Authors_Address3 Current Status: VASG-Approved Superseded By: ------------------------ Date Submitted: 24 January 2005 Date Analyzed: 10 February 2005 Author of Analysis: Peter Ashenden and Chuck Swart Revision Number: 7 Date Last Revised: 09 May 2005 Description of Problem ---------------------- A USE clause whose selected named identifies a (sub)type declaration makes that declaration potentially directly visible. Assuming that it does in fact become directly visible, the LRM is not clear on whether or not the implicit operators and literals of the type (if any) also become visible. At issue is whether the phrase "the identifier and the named entity (if any) are also said to be visible from that point", in which "named entity" means the type declaration, includes the operators and literals (if any). A similar rule for a non-object alias that denotes a type explicitly states that the literals and the operators have implicit alias declarations. For these declarations in package "pkg": TYPE enum is (red,green,blue,'A'); TYPE int is range 1 to 10; SUBTYPE xint is int range 3 to 7; Then USE work.pkg.enum; USE work.pkg.int; USE work.pkg.xint; makes exactly what visible? Note that "enum" is a type name, and "int" and "xint" are in fact the names of subtypes. Proposed Resolution ------------------- VASG-ISAC Analysis & Rationale ------------------------------ The submitter draws attention to the phrase "the identifier and the named entity (if any) are also said to be visible from that point," and asks whether this also refers to the operators and literals associated with the identifier. The answer to this becomes clear if you look at the context surrounding the phrase. It is part of 10.3, and is preceded by an extended description of when a declaration is visible. The complete paragraph containing the phrase is: Whenever a declaration with a certain identifier is visible from a given point, the identifier and the named entity (if any) are also said to be visible from that point. Direct visibility and visibility by selection are likewise defined for character literals and operator symbols. An operator is directly visible if and only if the corresponding operator declaration is directly visible. The first sentence simply defines terminology. It ascribes meaning to saying that an identifier is visible and that a named entity is visible, as distinct from saying that a declaration is visible. The second sentence similarly ascribes meaning to saying that a character literal or an operator symbol is visible, since they are defined by declarations. The third sentence describes conditions for an operator to be visible. Another key specification is in 10.4: If the suffix of the selected name is a simple name, character literal, or operator symbol, then the selected name identifies only the declaration(s) of that simple name, character literal, or operator symbol contained within the package or library denoted by the prefix of the selected name. This makes it clear that other names associated with the identified simple name, character literal or operator symbol are not identified by the selected name in the USE clause. Only the identified declarations are made potentially visible. So the best interpretation of the LRM is that, when you identify the name of a type or subtype in a USE clause, you only get that name made visible, and not any literals or operators defined either implicitly or explicitly. The obvious follow-on question is whether the LRM should be changed to make other declarations visible. However, I suspect this would be to open a can of worms. For example, should only predefined operations come along for the ride? What about overloads of predefined operations. What about overloads of operators that aren't predefined for the type? Should it just be operators, or other predefined operations? And so on... There are several possible solutions. We shall propose a restrictive solution and a more flexible one. 1. Do not change the LRM and interpret the visibility rules according to the above analysis. Designers can USE a type name, and add USE clauses for all the operators and enumeration literals associated with the type. Note that since USE clauses do not allow signatures, referencing an operator or an enumeration literal will make all such literals visible: there is no way to make only the operators and literals associated with a single type visible. In practice, this extra visibility should cause few problems. However, some designers feel that this strict interpretation of visibility makes USE clauses for types unworkable, since many operators and enumeration literals would have to be included in USE clauses. In addition, several current implementations currently interpret the LRM in a more flexible way, making some or all of the enumeration literals and/or operators visible when the type is made visible. These implementations might be reluctant to enforce the rigid interpretation, since it would negatively affect backward compatibility of their tools. 2. A useful solution is to make visible, along with the type all of its predefined operations, including all implicitly declared operations, enumeration literals (for enumeration types), and any units (for physical types). There is a question of whether overloaded operators should be included. If you view the visibility of "USE p.type1;" as a subset of the visibility raised by "USE p.all;", then, since USE p.all makes visible the overloaded operators and not the predefined operators, it makes sense to do the same for the USE type clause. In addition, if USE p.type1; makes the predefined operators visible, then USE p.type1; along with USE p.all; would make all overloaded operators and their corresponding predefined operators not visible because of homograph conflicts. Another question is whether to make the operators visible when the subtype is visible. When the subtype name is used in the type declaration (so the base type is anonymous) the operators should be made visible, since there is no way to name the base type. For other subtypes, such as xint in the example, the greatest utility will be achieved if the operators are made visible. 3. Visibility of aliases should be compatible with visibility of types, so changes in this area may also be needed. 4. There is a question of whether a USE type clause should create potential visibility for all operators and subprograms which reference the type in their profiles. This extension is considered to go too far, since such extensive use of the package should probably be accomplished by a USE p.all; statement. The ISAC recommends that paragraphs 2 and 3 above be adopted. Some additional issues: A) Consider: PACKAGE p1 IS TYPE enum1 IS (A,B,C,D); SUBTYPE enum2 is enum1 RANGE B TO C; END PACKAGE p1; ... USE work.p1.enum2; Which enums should be visible: all from enum1 or only those in range of enum2? Subtype declarations use subtype indications which are very general. For example, the following subtype declaration is legal in the context of the above example. SUBTYPE enum2 is enum1 RANGE A to general_function(1); If you were to USE enum2, the analyzer hasn't enough information to restrict the visibility of the enumeration literals from enum1. So the consensus is to make visible all enums from the base type B) Consider: PACKAGE p1 IS TYPE enum1 is (A,B,C,D); END PACKAGE p1; USE work.p1.ALL; PACKAGE p2 IS SUBTYPE enum2 is enum1 range B to C; -- overload the "=" operator from P1; FUNCTION "="(left,right:enum2) return BOOLEAN; END PACKAGE p2; USE work.p2.enum2; ENTITY e IS... What names/operators should be visible in entity e? The general consensus is that enum2 and the overloaded "=" operator declared in package p2 should be visible. This preserves the principle that USE p.x makes (potentially) visible a subset of USE p.ALL; C) IF a subtype is USEd should the base type become visible? Consider: PACKAGE p1 IS TYPE enum1 is (A,B,C,D); SUBTYPE enum2 is enum1; END PACKAGE p1; USE.work.p1.enum2; When enum2 is USED should enum1 also become visible? Argument in favor: The fundamental proposal for this IR is to make the predefined operators visible when the type or subtype is USED. The parameters to these operators are of the base type. It is confusing to have operators visible, but to have the types involved in the operator not visible. Argument against: Extra visible names pollute the name space. If you want the type to be visible then USE the type. Also, what about TYPE int1 IS RANGE 1 TO 10; SUBTYPE int2 IS int1 RANGE 2 TO 5; .... USE int2; In this case the base type is anonymous, but do you make the declared "first named subtype" int1 visible? If so, this might lead to a complicated set of rules determining which subtypes to make visible. The consensus is that if a subtype is USEd, then the corresponding base type is not made visible. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Assuming that Suggestions 2. and 3. are adopted make the following changes to the LRM. Clause 10.4 add after the paragraph starting "Each selected name in a use clause identifies...": "If the suffix is a type mark then the following declarations are identified: -- The declaration of the type or subtype denoted by the type mark -- If the type or subtype is a enumeration type, the enumeration literals of the base type -- If the type or subtype is a physical type, the units of the base type -- The implicit declarations of predefined operations for the type that are not hidden by homographs explicitly declared immediately within the package denoted by the prefix of the selected name -- The declarations of homographs, explicitly declared immediately within the package denoted by the prefix of the selected name, that hide implicit declarations of predefined operations for the type." Clause 4.3.3.2 Change part of c) from "If the name denotes an enumeration type..." to "If the name denotes an enumeration type or a subtype of an enumeration type..." Change part of d) from "if the name denotes a physical type..." to "if the name denotes a physical type or a subtype of a physical type..." Change part of e) from "if the name denotes a type..." to "if the name denotes a type or a subtype..." -------------END OF IR----------------