VHDL Issue Number: 2120 Language_Version VHDL-2002 Classification Language Modeling Enhancement or Deficiency Summary how to access objects in higher level nested protected type Relevant_LRM_Sections 3.5 Protected types 6.3 Selected names Related_Issues Key_Words_and_Phrases Authors_Name James Unterburger Authors_Phone_Number 503-685-0860 Authors_Fax_Number Authors_Email_Address jamesu@model.com Authors_Affiliation Mentor Graphics Authors_Address1 8005 SW Boeckman Rd Authors_Address2 Wilsonville, OR 97070 Authors_Address3 Current Status: Submitted Superseded By: ------------------------ Date Submitted: 22 August 2007 Date Analyzed: 13 September 2007 Author of Analysis: Peter Ashenden Revision Number: 1 Date Last Revised: 13 September 2007 Description of Problem ---------------------- The rules for selected names do not allow a prefix that is a type mark; when the prefix is an object of a protected type, the suffix must be the name of a method of that protected type. For nested protected types, in which an inner protected type body appearing within an outer protected type body (after the corresponding inner protected type declaration, of course) contains a declarative item with the same identifier as a declarative item appearing in the outer protected type body (declared prior to the appearance of the inner protected type body), it is impossible to refer to the outer protected type body's declarative item. type outer is protected end protected outer; type outer is protected body constant c : string := "Hello"; type inner is protected end protected inner; type inner is protected body -- this should work, "c" is still string here constant c : natural := c'length; -- won't work because how to get outer's c? -- "c" now means the natural, but selected -- name is illegal constant c1 : string := outer.c & " inner"; end protected body inner; end protected body outer; Proposed Resolution ------------------- Perhaps allow type mark prefix of selected name in this scenario. There may be other uses too, as in record_type_mark.record_element_name'left for example. VASG-ISAC Analysis & Rationale ------------------------------ The submitter is correct that the rules for a selected name do not allow for a type name as a prefix. Subclause 6.3 describes selected names that refer to record elements and objects designated by access values, and then identifies all remaining forms of selected names as expanded names. In the submitter's example, the name outer.c is intended to be an expanded name denoting the object named c declared within the enclosing protected type named outer. 6.3 allows use of expanded names to denote a named entity as follows: An expanded name denotes a named entity declared immediately within a named construct if the prefix denotes a construct that is an entity declaration, an architecture body, a subprogram declaration, a subprogram body, a block statement, a process statement, a generate statement, or a loop statement, and the suffix is the simple name, character literal, or operator symbol of a named entity whose declaration occurs immediately within that construct. This form of expanded name is only allowed within the construct itself. The rationale is that the simple name of the named entity may be hidden by another declaration nested within the declarative region formed by the enclosing construct. The expanded name provides a means of referring to the otherwise hidden named entity. The list of constructs comprises those in which such a scenario could reasonably occur. The remaining declarative regions omitted from the list are: - configuration declarations - record type declarations - component declarations - component configurations - protected type declarations With the exception of protected type declarations, the other regions have very restrictive purposes and there is little or no benefit to allowing expanded names for those regions. As the submitter pointed out, there is good reason for allowing expanded names in protected type declarations. It is likely that the omission of protected types as constructs for which expanded names were allowed was inadvertent when the protected type feature was added to the language. In order to include protected types to be permitted as enclosing constructs for expanded names, the quoted paragraph should be amended to include a protected type definition in the list. The second subsequent paragraph, starting "If, according to the visibility rules, ..." should be similarly amended. Note that the change should refer to a protected type definition, encompassing both protected type declarations and protected type bodies. While the requirement for expanded names in the context of a protected type declaration may not arise in the current revision of the language, it may do as the protected-type feature is evolved into a class-type feature as planned for future revisions. A subsequent paragraph in 6.3 also deals with expanded names for named entities declared with protected types: An expanded name denotes a named entity declared immediately within a protected type if the prefix denotes an object of a protected type and the suffix is a simple name of a method whose declaration appears immediately within the protected type declaration. This specification is intended to deal with method invocation. The named entity denoted by such an expanded name is, more strictly, the subprogram within the elaborated protected type of the object denoted by the prefix. By this means, a call distinguishes between the different elaborations of the subprogram that have different closures corresponding to different shared variables. Nonetheless, with expanded names being allowed within protected types, the intent of this paragraph is clouded. There is potential for confusion between the two forms of prefix for named entities declared with protected types. For that reason, it would be appropriate to amend this latter paragraph to be explicit in referring to the elaborated protected type. The rules in 10.3 concerning visibility also address expanded names occurring with constructs. Specifically, the paragraph: Finally, within the declarative region associated with a construct other than a record type declaration or a protected type, any declaration that occurs immediately within the region and that also occurs textually within the construct is visible by selection at the place of the suffix of an expanded name whose prefix denotes the construct. currently precludes protected types for consideration as the prefix of an expanded name. This paragraph should be amended by deleting the reference to protected types. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- Interpret the paragraphs in 6.3 and 10.2 as though the changes recommended for future revisions were made. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- In 6.3, change the following paragraphs: An expanded name denotes a named entity declared immediately within a named construct if the prefix denotes a construct that is an entity declaration, an architecture body, a subprogram declaration, a subprogram body, a block statement, a process statement, a generate statement, a loop statement, or a protected typ definition, and the suffix is the simple name, character literal, or operator symbol of a named entity whose declaration occurs immediately within that construct. This form of expanded name is only allowed within the construct itself. An expanded name denotes a named entity declared immediately within an elaborated protected type if the prefix denotes an object of a protected type and the suffix is a simple name of a method whose declaration appears immediately within the protected type declaration. If, according to the visibility rules, there is at least one possible interpretation of the prefix of a selected name as the name of an enclosing entity declaration, architecture, subprogram, block statement, process statement, generate statement, loop statement, or protected type, or if there is at least one possible interpretation of the prefix of a selected name as the name of an object of a protected type, then the only interpretations considered are those of the immediately preceding two paragraphs. In this case, the selected name is always interpreted as an expanded name. In particular, no interpretations of the prefix as a function call are considered.