These have both been updated in the on-line database. We'll discuss them at our next meeting on May25 (May 26th outside of US) Chuck Swart VHDL Issue Number: 2095 Language_Version VHDL-2002 Classification Language Definition Problem Summary What is the entity class of an enumeration literal? Relevant_LRM_Sections 5.1 Attribute specifications Related_Issues Key_Words_and_Phrases attribute specification, entity class, enumeration literal Authors_Name Peter Ashenden Authors_Phone_Number +61 414 709 106 Authors_Fax_Number Authors_Email_Address peter@ashenden.com.au Authors_Affiliation Ashenden Designs Authors_Address1 Authors_Address2 Authors_Address3 Current Status: Submitted Superseded By: ------------------------ Date Submitted: 13 May 2006 Date Analyzed: Author of Analysis: Revision Number: 0 Date Last Revised: Description of Problem ---------------------- An attribute specification uses the entity class of a named entity to identify the named entity to be decorated with an attribute. For an enumeration literal, it is not clear whether the entity class is literal or function. An enumeration literal is syntactically a literal, as specified by 7.3.1. However, 3.1.1 specifies that declaration of an enumeration literal is equivalent to declaration of a parameterless function returning the type of the enumeration literal. Moreover, 5.1 discusses subprograms and enumeration literals together in the context of appearance of a signature in an attribute specification. The question of the entity class of an enumeration literal is significant in the following ways: - If the wrong class is specified when an enumeration literal is named in an entity name list, it is an error. - If an attribute specification supplies the reserved word "all" or "others" in an entity name list and specifies the entity class "literal", are enumeration literals included? Similarly, if the entity class is "function", are enumeration literals included? Proposed Resolution ------------------- The description of attribute specifications does not require any particular entity classes to be specified in combination with a signature, only that, if a signature appears, the entity tags denote subprograms or enumeration literals. In the case of enumeration literals, it would thus not be contradictory for the entity class to be either "function" or "literal". Since an enumeration literal is defined to be a literal in 7.3.1, that would seem to be the preferred choice for its entity class. 5.1 should be amended to specify this explicitly. VASG-ISAC Analysis & Rationale ------------------------------ TBD VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD -------------END OF IR---------------- -------------BEGINNING OF IR---------------- VHDL Issue Number: 2094 Language_Version VHDL-2002 Classification Language Modeling Enhancement or Deficiency Summary Attribute specifications of overloaded subprograms is limited Relevant_LRM_Sections 5.1 Attribute specification Related_Issues Key_Words_and_Phrases attribute specification, entity class, overloading Authors_Name Lance Thompson Authors_Phone_Number 507.253.0145 Authors_Fax_Number Authors_Email_Address lancet@us.ibm.com Authors_Affiliation IBM Authors_Address1 Authors_Address2 Authors_Address3 Current Status: Analyzed Superseded By: ------------------------ Date Submitted: 5 May 2006 Date Analyzed: 14 May 2006 Author of Analysis: Peter Ashenden Revision Number: 1 Date Last Revised: 14 May 2006 Description of Problem ---------------------- Consider the following: attribute a : boolean; function sp( d:integer ) return integer; procedure sp( d:integer; z:integer ); attribute a of sp:function is true; attribute a of sp:procedure is true; There is a rule in 5.1 that basically prohibits this. "If a list of entity designators is supplied, then the attribute specification applies to the named entities denoted by those designators. It is an error if the class of those names is not the same as that denoted by the entity class." The rule seems to be overly restrictive. Proposed Resolution ------------------- Could the rule be extended to consider entities of the class denoted in the specification? That would almost eliminate the need for the error specification. Maybe something like: If a list of entity designators is supplied, then the attribute specification applies to the named entities denoted by those designators and of the class denoted in the specification. <delete?>It is an error if the class of those names is not the same as that denoted by the entity class.<end delete> VASG-ISAC Analysis & Rationale ------------------------------ The paragraph of 5.1 quoted by the submitter is part of a list of rules that determine to which named entities the attribute specification applies. A further rule states: An attribute specification whose entity designator contains no signature and identifies an overloaded subprogram or enumeration literal has the effect of associating that attribute with each of the designated overloaded subprograms or enumeration literals declared within that declarative part. The issue raised by the submitter is that a given name may be overloaded to denote entities of differing classes. In the submitter's example, the name sp denotes both a procedure and a function. The example could be extended with the following declaration: type enum is (sp, ...); in which case the name sp would also denote a literal (assuming that is the entity class of an enumeration literal). The rules quoted combine to make an attribute specification with no signature and with a name denoting overloaded entities of differing classes illegal, since one entity class must be specified, and not all of the overloaded entities are of that class. The attribute specification could be replaced with separate attribute specifications, each using a signature to match one of the overloaded entities, and each specifying the appropriate entity class. However, the submitter suggests changing the rules so that an attribute specification applies only to those overloaded entities of the specified class, regardless of whether there exist other entities of the same name of different classes. Thus, if there were multiple overloaded functions named sp, and multiple overloaded procedures named sp, the first of the submitter's attribute specifications would apply just to the functions, and the second would apply just to the procedures. In considering this proposal, we might attempt to discover the rationale for including the entity class in the first place. For entities that cannot be overloaded, the entity class does not serve to select among named entities, so it is semantically redundant. For entities that can be overloaded, the signature serves to select among entities of the given class. The signature uniquely identifies a named entity, and that entity is of a given class, so the entity class is again semantically redundant. For overloadable entities where no signature is specified, either all are of the same class, in which case specifying the class is semantically redundant; or the entities are of divers classes, in which case the problem identified by the submitter arises. In summary, for all cases of attribute specifications that list names of entities, the entity class specification is either redundant or makes the specification illegal. For attribute specifications that use "all" or "others", the entity class serves to select otherwise undecorated declarations to which the specification applies, viz, just those of the given class. In this case, the entity class is selective, serving to include some declarations and exclude others. Thus, it appears that the rationale for including the entity class in the attribute specification is mainly to provide this selective effect for the "all" and "others" cases. Including in the case of explicitly naming entities has no semantic significance; but it could be argued to have some documentation benefit. It is possible that the language designers did not anticipate the error condition arising in cases where there are multiple overloaded entities of different classes. The selective effect of the entity class is relevant to the submitter's example. Had the submitter instead written: attribute a of others:function is true; attribute a of others:procedure is true; the cited error would not occur, and the overloaded subprograms would be decorated as required. However, this would also decorate entities of other names than sp, which may not be intended. The submitter proposes simply to remove the requirement that the named entities me of the specified class, and only to apply the attribute to any entities of the given name that are of the specified class. On the case of multiple overloaded entities, the change has the desired effect. However, it also has a consequential effect for the common case of non-overloadable entities. For example, given a declaration of a type T, an attribute specification of the form attribute a of T: label is true; would, under the proposed change, silently not decorate T. This is undesirable. The submitter probably intended the change only to deal with the case of multiple overloaded entities, not this case. A possible change to the submitter's proposal would be to require that an attribute specification in which a name is given apply to at least one entity of that name and of the given class. That would preserve the current rule in the case of non-overloadable entities and in the case of overloaded entities, and would meet the submitter's requirement in the case of overloadable entities. We also need to consider the potential backward incompatibility of the proposed change. The change would not alter the effect of attribute specifications that are currently legal, since in all such attribute specifications, all entities named must be of the specified class, and only those entities are decorated. The change would not make any such cases illegal. The change would only alter attribute specifications that are currently illegal. Given that there is no concern with backward compatibility, and that the proposed change (as modified above) satisfies a use case currently excluded by the language, the change should be made. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No change, as the rules are clear. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Revise the paragraph in 5.1 that currently reads: If a list of entity designators is supplied, then the attribute specification applies to the named entities denoted by those designators. It is an error if the class of those names is not the same as that denoted by the entity class. to If a list of entity designators is supplied, then the attribute specification applies to the named entities denoted by those designators and of the class denoted by the entity class. It is an error if any entity designator denotes no named entity of the class. -------------END OF IR----------------Received on Wed May 17 15:26:03 2006
This archive was generated by hypermail 2.1.8 : Wed May 17 2006 - 15:26:04 PDT