EnhancedGenericsInAttributeSpecs < P1076

P1076 Web>Vhdl2019CollectedRequirements>EnhancedGenericsInAttributeSpecs (2020-02-17, JimLewis) (raw view)EditAttach
---+ Define Entity Classes of 2008-Related Declarations in Attribute Specifications

%TOC%

---++ Proposal Details
   * Who Updates: main.CliffordWalinsky ,
   * Date Proposed:January 2, 2013
   * Date Last Updated:
   * Priority:
   * Complexity:
   * Focus:General Language
   * LCS: [[LCS2016_I04][LCS-2016-I04]]

---+++ Summary

Revise Section 7.2 to explicitly describe the entity classes of enhanced generics, and describe how a signature within an entity designator is used to match interface subprograms and subprogram instances.
---+++ Current Situation

Currently, Section 6.7 "Attribute declarations" states that:

"An attribute may be associated with an entity declaration, an architecture, a configuration, a procedure, a function, a package, a type, a subtype, a constant, a signal, a variable, a component, a label, a literal, a unit, a group, or a file."

There is no allowance for attributes to be associated with subprogram instances, interface subprograms, package instances, or interface packages. [There are 2 other entities not included in this list that exist in the list of entity classes: properties and sequences; presumably, these entities should also be added.]

Similarly, Section 7.2 "Attribute specifications" makes no mention of the above entity classes. Therefore, it is never made explicit that procedure instances and interface procedures are of entity class *procedure*, that function instances and interface functions are of entity class *function*, or that package instances and interface packages are of entity class *package*. It may be that new entity classes could be defined for subprogram instances, interface subprograms, package instances, and interface packages.
---+++ Candidate: Map New Entity Classes to Existing Classes

As suggested in the description of the current situation, it is desirable to group all procedure-related entities in the procedure entity class, function-related entities in the function entity class, and package-related entities in the package entity class. We suggest the following statements:
   * If a name in an entity name list denotes a procedure instance, its entity class is *procedure*. A signature within the entity designator should match the parameter profile of the associated uninstantiated procedure.
   * If a name in an entity name list denotes an interface procedure, its entity class is *procedure*. A signature within the entity designator should match the parameter profile of the designator associated with the interface procedure's declaration.
   * If a name in an entity name list denotes a function instance, its entity class is *function*. A signature within the entity designator should match the parameter and return profile of the associated uninstantiated function.
   * If a name in an entity name list denotes an interface function, its entity class is *function*. A signature within the entity designator should match the parameter and return profile of the designator associated with the interface function's declaration.
   * If a name in an entity name list denotes a package instance or interface package, its entity class is *package*.

As an example of the meaning of an attribute specification applied to an interface procedure, assume an uninstantiated package declaration contains the following interface procedure declaration in its generic list:

<verbatim style="padding-left: 30px;">procedure int_foo(x : bit) is <></verbatim>

The following attribute declaration and specification apply to int_foo.

<verbatim style="padding-left: 30px;">attribute proc_attr : integer;
attribute proc_attr of int_foo [bit] : procedure is 5;</verbatim>
---+++ Candidate: Create New Entity Classes

This is a less attractive alternative to the previous proposal. Rather than mapping variants of subprograms to <strong>procedure </strong>and *function* classes, and variants of packages to entity class *package*, this candidate proposal defines new entity classes for each variant. As an example, we could define entity class *interface_function*. Six new entity classes would be defined. In a sense, the newly defined entity classes are a departure from the pattern set for other entity classes. The new entity classes not only describe syntactic characteristics, but they also describe the way in which the entities have been declared. In the example of the *interface_function* entity class, entities that match this class have been declared in generic lists. For an existing class like<strong> constant</strong>, entities that match this class may be declared within declarative regions as constants, but also may be declared as input parameters to subprograms. The advantage of this proposal is that there is complete differentiation between the various ways in which subprograms and packages are declared.
---++ Analysis

-- Main.JimLewis - 2017-01-16

*Definition of user defined attributes from section 6.7 Attribute declarations page 92:*

User-defined attributes are constants of arbitrary type. Such attributes are defined by an attribute declaration.

<br /> attribute_declaration ::= %BR%<br />     attribute identifier : type_mark ;

<br />The identifier is said to be the designator of the attribute. An attribute may be associated with an entity<br />declaration, an architecture, a configuration, a procedure, a function, a package, a type, a subtype, a<br />constant, a signal, a variable, a component, a label, a literal, a unit, a group, or a file.

<b>Analysis:  <br /></b>

Like most things, the writing here could be updated. The sentenced mentioned above that starts with<br />"An attribute may" simply provides an example of the items that may have an attribute. It does not use<br />the words "shall be one of the following", and hence, while potentially confusing, it is not required to be<br />a list of all the entity_class items that are part of an attribute declaration.  

Since text is talking about entity_class items, which are part of attribute specifications and not attribute<br />declarations, it is an appropriate discussion for section 7.2 which already has an enumeration of the <br />constructs that are part of entity_class.

If we were going to re-write this for clarity, I suggest that we delete the list as it is hard to maintain overtime, particularly since simply restates information that is the topic of another section.

*Candidate Re-write:*  

User-defined attributes are constants and are defined by an attribute declaration.

<br /> attribute_declaration ::= %BR%<br />     attribute identifier : type_mark ;

The identifier defines the simple_name of the attribute. The type_mark designates the type of the constant.

*Further Issues in section 6.7 page 92:*  

Note 2 is poorly written. It refers to a named entity and a declaration in the same sentence. However, it takes an attribute specification to associate a named entity with a user defined attribute.<br />Hence, this note could be re-written and moved to section 7.2 attribute specification.

The sense of note 2 is that the name provided in the entity_designator is associated with the named entity denoted by the name and not the name itself.  Hence, aliases, ...

This also implies that any name that denotes a function has entity class function.

Notes 1 and 3 also apply to attribute specifications and need to be moved to section 7.2.

Note 4 was deleted by another LCS.

<b>Summary: <br /></b>

The sense of the LRM is there.  The text is just confusing.  We could do this now, however, <br />there is alot of other clean-up work that needs to be done, but will not get done during this <br />revision.  Since we have an issue report against this, perhaps we should do it now.
---++ Arguments FOR
---++ Arguments AGAINST
---++ General Comments
---++ Supporters

_Add your signature here to indicate your support for the proposal_
Topic revision: r9 - 2020-02-17 - 15:34:29 - JimLewis
P1076