EXPRESS_ — Distinguishing instances of AGGREGATEType

Clause 8.10.1 is not clear as to how instances of AGGREGATEType are distinguished. Those with different type_labels should be different, but 8.10.1 doesn't say so, and it doesn't model the labels. Those with the same type_label are treated as constraints. But what about AGGREGATEs with no type labels? For exchange purposes, we need to agree on how to distinguish instances.

Then in Clause 10.4.2, an ActualAggregateType refers to an ActualStructure, but an ActualStructure doesn't have any relationship to an AGGREGATE type. So how is the type derivation relationship determined? It is possible that the parameter type of the :source Parameter involves two AGGREGATE types, e.g.:
FUNCTION F(x: AGGREGATE:a [1:?] OF AGGREGATE:b [0:?] OF GENERIC):REAL;
In clause 8.10, the AGGREGATETypes do not have type_labels, so it is not clear whether to match the ActualStructure labeled "a" to the AGGREGATE of AGGREGATE or to the AGGREGATE of GENERIC.

(This problem does not arise for ActualDataType, because there can be only one GENERIC or GENERIC_ENTITY type in the :source Parameter.)

Proposed change:

Clarify how instances of AGGREGATEType are distinguished. And either give them a label, or create a relationship from ActualStructure to AGGREGATEType.

(Note: The resolution incorporates changes in terminology that were adopted by Issue 14070.)
For each syntactic occurrence of GENERIC, GENERIC_ENTITY or AGGREGATE that defines a type_label, there is a corresponding ParametricElement that defines that type_label. Other syntactic occurrences with that type_label represent ActualTypes and ActualTypeConstraints or ActualStructureConstraints that refer to that ParametricElement.
Each syntactic occurrence of AGGREGATE is a distinct instance of AGGREGATEType. It is not modeled as having a type_label, because two distinct AGGREGATETypes can have the same type_label. The specification will be modified to make this clear.
The type_label on an occurrence of AGGREGATE serves to label the associated ParametricStructure, or to associate ActualTypes and ActualStructureConstraints with it. Since there may be more than one such structural element in the parameter-type of a given Parameter, each ParametricStructure must be associated with the specific AGGREGATEType. ParametricStructure is not a subtype of AGGREGATEType; it is associated with one. The specification will be corrected.
In resolving this issue, it was observed that a similar ambiguity exists with respect to GENERIC:tag and GENERIC_ENTITY:tag. It is not clear how many GenericTypes there are. This problem was resolved as follows:
There are exactly two GenericTypes (GENERIC, GENERIC_ENTITY) and they don't have type_labels. The definition of GenericType is incorrect in this regard, and the :isEntity attribute serves no purpose. isEntity is properly an attribute of ParametricTypes - the ParametricElements that correspond to GENERIC:tag and GENERIC_ENTITY:tag. The model will be corrected.
The type_label on an occurrence of GENERIC or GENERIC_ENTITY serves to label the ParametricType, or to associate ActualTypes and ActualTypeConstraints with it. ParametricType is not a subtype of GenericType; the specification will be corrected.
All occurrences of GENERIC refer to the same type; and all occurrences of GENERIC_ENTITY refer to the same type. Therefore, the ParametricType based on a GENERIC:tag component has no distinguishing type to refer to. The occurrence of GENERIC or GENERIC_ENTITY, however, must be unique within a ParameterType; so the referent of the ParametricType is implicit in the :source (Parameter or Attribute) that has the ParameterType. The model is modified to reflect this design.
Summary: The technical changes are conceptually three:

• AGGREGATEType and GenericType are clarified.
• ParametricElements are not parts or specializations of GeneralizedTypes
• ParametricStructures are associated with specific AGGREGATETypes.
  The resolution of Issue 14194 simplifies the change somewhat, by moving most of the affected text from Clause 10 into Clause 8. So all of the technical changes are incorporated in the resolution of Issue 14194.
  Revised Text:
  The corresponding model and text changes are included under Issue 14194.
  Disposition: Merged into Issue 14194