-------------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: VASG-Approved Superseded By: ------------------------ Date Submitted: 5 May 2006 Date Analyzed: 14 May 2006 Author of Analysis: Peter Ashenden Revision Number: 3 Date Last Revised: 24 August 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. It is an error if the class of those names is not the same as that denoted by the entity class. 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----------------