(r4) EnhancedGenericsInAttributeSpecs < P1076/Ballots

P1076/Ballots Web>Vhdl2019CollectedRequirements>EnhancedGenericsInAttributeSpecs (revision 4) (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
---+++ 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.
---++ Use Cases
---++ Arguments FOR
---++ Arguments AGAINST
---++ General Comments
---++ Supporters

_Add your signature here to indicate your support for the proposal_
Topic revision: r1 - 2020-02-17 - 15:34:52 - TWikiGuest
P1076/Ballots