CVS difference for ai05s/ai05-0183-1.txt
--- ai05s/ai05-0183-1.txt 2010/05/20 03:23:30 1.6
+++ ai05s/ai05-0183-1.txt 2010/06/11 02:25:44 1.7
@@ -1,4 +1,4 @@
-!standard 3.2.1(2) 10-04-27 AI05-0183-1/03
+!standard 3.2.1(2) 10-06-07 AI05-0183-1/04
!standard 3.2.2(2)
!standard 3.3.1(2/2)
!standard 3.8(6)
@@ -14,12 +14,15 @@
!standard 9.4(2/2)
!standard 9.4(3/2)
!standard 9.5.2(2/2)
+!standard 11.1(2)
!standard 12.1(3)
+!standard 12.3(2/2)
!standard 12.4(2/3)
!standard 12.5(2)
!standard 12.6(2.1-2.2/2)
!standard 12.7(2)
!standard 13.1(0.1/2)
+!standard 13.3(5/1)
!standard 13.3.1(0)
!class amendment 09-11-01
!status work item 09-11-01
@@ -77,10 +80,14 @@
* protected_type_declaration;
* single_protected_declaration;
* entry_declaration;
+ * exception_declaration;
* generic_declaration;
+ * generic_instantiation;
* generic_formal_parameter_declaration.
- [What about renaming declarations?]
+Aspect specification are not permitted on renaming declarations, as
+that would seem to break the underlying model of renaming (that properties are
+the same as the renamed entity).
At most one occurrence of each aspect is allowed within a single aspect_specification.
The named aspect must be an aspect that can be specified for the given kind of entity.
@@ -209,6 +216,11 @@
ENTRY defining_identifier [(discrete_subtype_definition)] parameter_profile
[aspect_specification];
+Replace 11.1(2) by:
+
+ exception_declaration ::= defining_identifier_list : exception
+ [aspect_specification];
+
Replace 12.1(3) by:
generic_subprogram_declaration ::=
@@ -219,6 +231,21 @@
[AARM NOTE: a generic package can have an aspect_specification
because a package_specification allows an aspect_specification.]
+Replace 12.3(2/2) by:
+
+ generic_instantiation ::=
+ package defining_program_unit_name is
+ new generic_package_name [generic_actual_part]
+ [aspect_specification];
+ | [overriding_indicator]
+ procedure defining_program_unit_name is
+ new generic_procedure_name [generic_actual_part]
+ [aspect_specification];
+ | [overriding_indicator]
+ function defining_designator is
+ new generic_function_name [generic_actual_part]
+ [aspect_specification];
+
Replace 12.4(2/3) by:
formal_object_declaration ::=
@@ -255,6 +282,12 @@
specified using an aspect_specification (see 13.3.1), which is an optional
element of certain kinds of declarations.
+Revise 13.3(5/1) as follows:
+
+ ... Each specifiable attribute constitutes an operational aspect or
+ aspect of representation{; the name of the aspect is that of the
+ attribute}.
+
Add the following section:
13.3.1 Aspect Specifications
@@ -268,47 +301,44 @@
Syntax
aspect_specification ::=
- WITH aspect_mark [=> expression] {,
- aspect_mark [=> expression] }
+ WITH aspect_mark [=> aspect_definition] {,
+ aspect_mark [=> aspect_definition] }
aspect_mark ::= aspect_identifier['Class]
- AARM NOTE: The aspect_specification is an optional element in the following
- kinds of declarations:
- * object_declaration;
- * full_type_declaration;
- * subtype_declaration;
- * component_declaration;
- * subprogram_declaration;
- * abstract_subprogram_declaration;
- * null_procedure_declaration;
- * package_declaration;
- * private_type_declaration;
- * private_extension_declaration;
- * task_type_declaration;
- * single_task_declaration;
- * protected_type_declaration;
- * single_protected_declaration;
- * entry_declaration;
- * generic_declaration.
- End AARM Note.
+ aspect_definition ::= name | expression
Name Resolution
- The expected type for an expression associated with a given
- aspect_mark is the type of the identified aspect of the entity defined
- by the associated declaration (the *associated entity*). The names in
- such an expression [Redundant: are not resolved at the point of the
- associated declaration, but rather] are resolved at the end of the
- immediately enclosing declaration list or at the first freezing point
- of the associated entity, whichever comes first.
+ An aspect_mark identifies an aspect of the entity defined by the
+ associated declaration (the *associated entity*); the aspect denotes
+ an object, a value, an expression, a subprogram, or some other kind of
+ entity. If the aspect_mark identifies an aspect that denotes an
+ object, the aspect_definition shall be a name. If the aspect_mark
+ identifies a value or an expression, the aspect_definition shall be an
+ expression. The expected type for the name or expression is the type
+ of the identified aspect of the associated entity.
+
+ If the aspect_mark identifies an aspect that denotes a subprogram, the
+ aspect_definition shall be a name; the expected profile for the name
+ is the profile required for the aspect of the associated entity. If
+ the aspect_mark identifies an entity that denotes some other kind of
+ entity, the aspect_definition shall be a name, and the name shall
+ resolve to denote an entity of the appropriate kind.
+
+ The names in an aspect_definition [Redundant: are not resolved at the
+ point of the associated declaration, but rather] are resolved at the
+ end of the immediately enclosing declaration list, or at the first
+ freezing point of the associated entity, whichever comes first.
If the associated declaration is for a subprogram or entry, the names of the
- formal parameters are visible within the expression, as are certain
- attributes, as specified elsewhere in this International Standard for
- the identified aspect. If the associated declaration is a type_declaration,
- within the expression the names of any components are visible, and the
- name of the first subtype denotes the current instance of the type (see 8.6).
+ formal parameters are visible within the aspect_definition, as are certain
+ attributes, as specified elsewhere in this International Standard for the
+ identified aspect. If the associated declaration is a type_declaration, within
+ the aspect_definition the names of any components are visible, and the name of
+ the first subtype denotes the current instance of the type (see 8.6). If the
+ associated declaration is a subtype_declaration, within the aspect_definition
+ the name of the new subtype denotes the current instance of the (sub)type.
Legality Rules
@@ -316,24 +346,26 @@
aspect_specification. The aspect identified by the aspect_mark
shall be an aspect that can be specified for the associated entity.
- The expression associated with a given aspect_mark may be omitted only
+ The aspect_definition associated with a given aspect_mark may be omitted only
when the aspect_mark identifies an aspect of a boolean type, in which
- case it is equivalent to the expression being specified as True.
+ case it is equivalent to the aspect_definition being specified as True.
If the aspect_mark includes 'Class, then the associated entity shall be
- a tagged type, or the primitive subprogram of a tagged type.
+ a tagged type or the primitive subprogram of a tagged type.
- Additional legality rules may apply, as specified elsewhere in this
- International Standard for particular aspects.
+ Alternative legality and semantics rules may apply for particular
+ aspects, as specified elsewhere in this International Standard.
Static Semantics
- Depending on the aspect identified by the aspect_mark, an aspect_specification
- specifies either a single value, or an expression (such as a precondition)
- that is to be evaluated at particular points during later execution.
- The identified aspect of the associated entity is as specified by the
- expression (or by the default of True when boolean). If the aspect_mark
- includes 'Class, then:
+ Depending on the aspect identified by the aspect_mark, an
+ aspect_definition specifies a name that denotes a subprogram, object,
+ or other kind of entity, or an expression, which is either evaluated
+ to produce a single value, or which (as in a precondition) is to be
+ evaluated at particular points during later execution. The identified
+ aspect of the associated entity is as specified by the
+ aspect_definition (or by the default of True when boolean). If the
+ aspect_mark includes 'Class, then:
* if the associated entity is a tagged type, the specification
applies to all descendants of the type;
@@ -344,14 +376,83 @@
Dynamic Semantics
- At the freezing point of the associated entity, the aspect_specification
- is elaborated. The elaboration of the aspect_specification includes the
- evaluation of the expression, if the corresponding aspect is a value rather
- than an expression. If the corresponding aspect represents an
- expression, the elaboration has no effect; the expression is evaluated
+ At the freezing point of the associated entity, the aspect_specification is
+ elaborated. The elaboration of the aspect_specification includes the
+ evaluation of the name or expression, unless the aspect itself is an
+ expression. If the corresponding aspect represents an expression (as in a
+ precondition), the elaboration has no effect; the expression is evaluated
later at points within the execution as specified elsewhere in this
International Standard for the particular aspect.
+ AARM NOTE: The aspect_specification is an optional element
+ in the following kinds of declarations:
+ * object_declaration;
+ * full_type_declaration;
+ * subtype_declaration;
+ * component_declaration;
+ * subprogram_declaration;
+ * abstract_subprogram_declaration;
+ * null_procedure_declaration;
+ * package_declaration;
+ * private_type_declaration;
+ * private_extension_declaration;
+ * task_type_declaration;
+ * single_task_declaration;
+ * protected_type_declaration;
+ * single_protected_declaration;
+ * entry_declaration;
+ * exception_declaration;
+ * generic_declaration;
+ * generic_instantiation;
+ * generic_formal_parameter_declaration.
+
+ Here is a list of all kinds of declarations and an indication
+ of whether or not they allow aspect clauses, and in some cases
+ a short discussion of why (* = allowed, NO = not allowed)
+
+ basic_declaration
+ type_declaration
+ full_type_declaration*
+ ...
+ task_type_declaration*
+ protected_type_declaration*
+ incomplete_type_declaration -- NO
+ private_type_declaration*
+ private_extension_declaration*
+ subtype_declaration*
+ object_declaration*
+ ...
+ single_task_declaration*
+ single_protected_declaration*
+ number_declaration -- NO
+ subprogram_declaration*
+ abstract_subprogram_declaration*
+ null_procedure_declaration*
+ package_declaration*
+ renaming_declaration -- NO
+ -- Allowing a renaming to change operational or representational
+ -- aspects would seem to break the underlying model of renaming.
+ exception_declaration*
+ generic_declaration*
+ generic_instantiation*
+ enumeration_literal_specification -- NO
+ discriminant_specification -- NO
+ component_declaration*
+ loop_parameter_specification -- NO
+ parameter_specification -- NO
+ subprogram_body -- NO
+ entry_declaration*
+ entry_index_specification -- NO
+ choice_parameter_specification -- NO
+ generic_formal_parameter_declaration*
+ -- There are no language-defined aspects that
+ -- may be specified on generic formals, but implementations
+ -- might support some. The implementation would have to
+ -- define the matching rule.
+ extended_return_statement -- NO
+ End of AARM Note.
+
+
!discussion
This syntax was invented to allow pre- and postconditions to be specified
@@ -383,9 +484,9 @@
type R is record
X : Positive := 0
- with Independent; -- Independence?
+ with Independent => True;
Y : Natural := 77
- with Atomic; -- Atomicity?
+ with Atomic => True;
end record;
type Shared_Bit_Vector is array(0..15) of Boolean
@@ -395,10 +496,15 @@
with Component_Size => 1;
This presumes that aspect identifiers generally match attribute names or
-pragma names. However, particularly in the case of pragmas, we may
-prefer to choose nouns rather than adjectives for aspect names, so the
-names work better after the preposition "with". Hence, perhaps
-"Atomicity" or "Independence" rather than "Atomic" and "Independent."
+pragma names. We considered, in the case of pragmas, choosing nouns
+rather than adjectives for aspect names, so the names might work better
+after the preposition "with". Hence, we considered "Atomicity" or
+"Independence" rather than "Atomic" and "Independent." However, that
+seemed to be introducing unnecessary complexity, and adding "=> True"
+makes the adjectives work grammatically, so by default the aspect
+name will be presumed to be the same as the pragma. Pragma Pack
+currently specifies that its aspect is "packing," but we might want to
+change that for consistency. See AI05-0112-1.
We use "'Class" as an indication that the aspect specification applies
to all descendants of the type, or for a subprogram, the corresponding
@@ -1037,6 +1143,55 @@
should be legal. So should this:
with Predicate => Part.Num_Players in 1 .. Part.Max_Players;
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, June 7, 2010 2:58 PM
+
+Here is an update to the aspect specification AI. [This is version /04 - Editor.]
+There are still some things missing, such as the
+Annex of specifiable aspects. I am
+also a little unclear how we should
+indicate in the body of the RM
+(as opposed to in the eventual annex) which aspects can be specified.
+
+My guess is that all specifiable attributes should be specifiable using an
+aspect_specification. But it is not clear which pragmas nor
+which of the other aspects associated
+with record and enum rep clauses should
+be specifiable with an aspect_specification.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, June 10, 2010 9:22 PM
+
+> Here is an update to the aspect
+> specification AI. There are still
+> some things missing, such as the
+> Annex of specifiable aspects. I am
+> also a little unclear how we should
+> indicate in the body of the RM
+> (as opposed to in the eventual annex)
+> which aspects can be specified.
+
+So are the rest of us! Someone needs to invent something, and you're one of the
+best inventors.
+
+> My guess is that all specifiable attributes should be specifiable
+> using an aspect_specification.
+> But it is not clear which pragmas nor
+> which of the other aspects associated
+> with record and enum rep clauses should be specifiable with an
+> aspect_specification.
+
+I think a straw-man here would be helpful. I'm not even sure that most of us are
+considering everything that might be possible to specify.
+
+So I think it would be helpful if you would make a stab at figuring how these
+things might work. (But only after the rest of your homework is done, the two
+remaining AIs are more important than these details of this one.)
****************************************************************
Questions? Ask the ACAA Technical Agent