VHDL Issue Number: 1074 Classification: Language Definition Problem Language Version: VHDL-93 Summary: Interpretation of overloaded name prefixes is unclear. Related Issues: 0006, 0047, 0108, 0109 Relevant LRM Sections: 6.1, 10.3, 10.5 Key Words and Phrases: Prefix, names, visibility, overload resolution Current Status: Analyzed 1076-1993 Disposition: N/A Disposition Rationale: N/A Superseded By: N/A ----------------------- Date Submitted: 1989/02/06 Author of Submission: Paul Menchini 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: mench@clsi.com ----------------------- Date Analyzed: 1991/01/18 Author of Analysis: Paul Menchini (mench@clsi.com) Revision Number: $Revision: 1.1 $ Date Last Revised: $Date: 1995/07/26 17:56:33 $ Description of Problem ---------------------- It is unclear whether or not the prefix of a non-simple name is allowed to have more than one interpretation in a given context. If it is, it is then also not clear how the correct interpretation is to be determined. Section 10.3 defines "visibility by selection." Section 10.5 states that overloading is defined for subprograms (including functions). Section 6.1 allows a function call as the prefix of a non-simple name. However, the remainder of Chapter 6 takes for granted that the prefix of a non-simple name can be unambiguously determined (or at least that at most one prefix results in a visible suffix). This state of affairs is not always possible. Consider the following example: -- Example 1: type R1 is record I: integer; end record; type R2 is record J: real; end record; function F return R1; function F return R2; constant C: Integer := F.I; Here, the intendened interpretation is clear: the prefix "F" is a call to the function returning an R1 and the suffix "I" is a reference to the element "I" of the returned value of F. No "I" is visible if the prefix is interpreted as a function call returning an R2, and type information is needed to disambiguate the name. But, is this kind of analysis allowed by the LRM? Is it required by the LRM? The situation is more complex in the next example: -- Example 2: type R1 is record I: integer; end record; type R2 is record I: real; end record; function F return R1; function F return R2; constant C: Integer := F.I; In this example, if "F.I" is to be interpreted, type information must be used to interpret the prefix of "F.I"; the intended interpretation is again the F returning an R1. It is not clear whether the LRM prohibits, allows, or requires this analysis. These examples could be made more complex by utilizing functions returning arrays, or access values, etc., and by having the name involve implicit dereferencing and default parameters, but the basic problem is outlined here. Proposed Resolution ------------------- Explicitly state in Section 6.1 that prefixes of non-simple names may be overloaded function calls. Further state that the interpretation of the prefix depends on two factors: 1. The identity of what follows the prefix. This may have to be individually discussed for each type of non-simple name. For example, if the name is a selected name, the prefix must be "appropriate" for the suffix in that the suffix must have a meaning in the context of the prefix according to the visibility rules. Thus, the visibility rules of Section 10.3 may be used to "pare down" the number of acceptable possible meanings. 2. The rules governing overload analysis in Section 10.5 may be used to further eliminate possible meanings. If, after both rules are applied, exactly one possible meaning for a name does not remain, the name is in error. VASG-ISAC Analysis & Rationale ------------------------------ This issue was considered together with issues 47, 108, and 109. The following analysis, rationale, 1987 recommendation, and future recommendation applies to issues 47 and 108 in addition to this issue. Issue 109 is sufficiently different from the others that it is considered separately. In general, an approach based on the Ada resolution to these same issues is favored. VASG-ISAC Recommendation for IEEE Std 1076-1993 ----------------------------------------------- Determine the denotation of all names of the form "prefix . suffix" as follows: 1. Determine whether the name can be interpreted as a selected name or an expanded name. If it can be interpreted both as a selected name and as an expanded name, then favor the expanded interpretation. (This is how Ada handles this case.) Only visibility checks may be performed when testing for each of these interpretations; in particular, no type information can be used in this step. 2. If the name is an expanded name, then the prefix must not be ambiguous in the innermost complete context. That is, the prefix as a name, must be unambigous. Neither the suffix, nor the fact that the prefix is a prefix of an expanded name, may be used to disambiguate the prefix. (This, too, is from Ada.) 3. If the name is a selected name, the suffix and the innermost complete context may be used to disambiguate the name. Type information may be used in this disambiguation. (Also from Ada.) Under these rules, "F.I" from Example 1 of this issue is the Integer element of a value of type R1 (i.e., "F" denotes the function returning a value of type R1 and "I" denotes the single element of this type). Example 2 of this issue is interpreted likewise. The name "f.x" in the first example in Issue 47 now means the real variable declared in the innermost function. Likewise, "x.f" in the second example in Issue 47 means the first variable declared in the function x. The name "F.A" in the example in Issue 108 means the variable A under this interpretation. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Add language to the LRM to effect this interpretation.