VHDL Issue Number: 0044 Classification: Language Definition Problem Language Version: VHDL-87 Summary: A name with an access object as a prefix can be a locally static name. Related Issues: none Relevant LRM Sections: 6.1 Key Words and Phrases: static names, locally static names, aliases, access types Current Status: Submitted 1076-1993 Disposition: Closed (All Issues Completely Addressed) Disposition Rationale: VHDL-93 LRM was revised. Superseded By: N/A ---------------------- Date Submitted: 1988/11/02 Author of Submission: Doug Dunlop Author's Affiliation: Intermetrics Author's Post Address: 4733 Bethesda Ave #415 Bethesda, MD 20814 Author's Phone Number: (301) 657-3775 Author's Fax Number: Author's Net Address: dunlop%inmet.inmet.com@uunet.uu.net ------------------------ Date Analyzed: 1988/11/02 Author of Analysis: Doug Dunlop Revision Number: $Revision: 1.9 $ Date Last Revised: $Date: 1995/08/03 00:23:18 $ Description of Problem ---------------------- If P is an access object whose designated type is a record type containing an element F, the name P.F is a locally static name according to the LRM. There are no expressions that appear as part of this name (in particular P is not an expression in this context); hence by definition it is a locally static name (refer to the paragraph immediately above the examples in LRM 6.1). It is also by definition a (globally) static name. Neither of these is intended by the language design. A locally static name that denotes an object is such that a unique object is denoted and this particular object can be determined prior to the elaboration of the model (e.g., at "analysis time"). A (globally) static name denoting an object is such that a unique object is denoted and this particular object can be determined immediately after the elaboration of the model. In the above example with P.F, no unique object is necessarily denoted as P can vary in value during simulation. Hence, to match the intent of the language design, P.F should be neither a locally static name nor a (globally) static name. An example problem caused by the mismatch between the intent of the language design for locally static names and their technical definition given in the LRM is variable assignment statements whose target is in the form of an aggregate (LRM 8.4). The expressions in the element associations of the aggregate are required to be locally static names so that it is possible at analysis time to perform the check concerning a variable being identified by more than one element association (fourth paragraph, LRM 8.4). With the technical definition of a locally static name this is impossible. An example problem caused by the mismatch between the intent of the language design for (globally) static names and their technical definition given in the LRM is alias declarations. The object being aliased must be denoted by a (globally) static name to guarantee that the alias always denotes the same object throughout the scope of the alias. Without this guarantee, the LRM would have to specify when the name denoting the aliased object is evaluated to determine the object the alias denotes. Perhaps related to this problem of access objects as a name prefix is a function call as a name prefix. For example, if F is a function whose return type is a record containing an element X, should F.X be a locally static name? Globally static? The answers to these questions seem to be that it does not matter. F.X in this case does not denote an object; hence it does not make sense to ask if it always denotes the same object. This fits with the LRM in the sense that locally (or globally) static names are required only in contexts that also require names denoting objects. Hence it is all right in terms of the Language Definition Problem if F.X in this case is a locally static name. This agrees with the LRM definition of a locally static name. Therefore, no LRM interpretation is required for the case of a function call as the prefix in a name. Proposed Resolution ------------------- The text from the paragraph immediately above the examples in LRM 6.1 that reads A name is said to be a static name if every expression that appears as part of the name (for example, as an index expression) is a static expression. Furthermore, a name is said to be a locally static name if every expression that appears as part of the name is a locally static expression. should be read as A name is said to be a static name if every expression that appears as part of the name (for example, as an index expression) is a static expression and if no prefix within the name is an object or value of an access type. Furthermore, a static name is said to be a locally static name if every expression that appears as part of the name is a locally static expression. Note that this resolution allows a static name to be of an access type. This seems proper. VASG-ISAC Analysis & Rationale ------------------------------ The above analysis appears accurate and the recommendation seems sound. VASG-ISAC Recommendation for IEEE Std 1076-1987 ----------------------------------------------- The above re-wording of LRM 6.1 should be assumed. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Incorporate the above change into the text of the LRM. To reduce confusion, it may be desireable in the long term to define static names so that these names always denote objects.