Define Entity Classes of 2008-Related Declarations in Attribute Specifications

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:

procedure int_foo(x : bit) is <>

The following attribute declaration and specification apply to int_foo.

attribute proc_attr : integer;
attribute proc_attr of int_foo [bit] : procedure is 5;

Candidate: Create New Entity Classes

This is a less attractive alternative to the previous proposal. Rather than mapping variants of subprograms to procedure 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 constant, 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