CVS difference for ai05s/ai05-0183-1.txt
--- ai05s/ai05-0183-1.txt 2010/09/04 02:49:25 1.10
+++ ai05s/ai05-0183-1.txt 2010/10/26 00:01:34 1.11
@@ -1,4 +1,4 @@
-!standard 3.2.1(3) 10-09-01 AI05-0183-1/05
+!standard 3.2.1(3) 10-10-25 AI05-0183-1/06
!standard 3.2.2(2)
!standard 3.3.1(2/2)
!standard 3.8(6)
@@ -288,6 +288,22 @@
specified using an aspect_specification (see 13.3.1), which is an optional
element of certain kinds of declarations.
+Modify 13.1(9, 9.1/1) as follows:
+
+ A representation item that directly specifies an aspect of a subtype
+ or type shall appear after the type is completely defined (see
+ 3.11.1), and before the subtype or type is frozen (see 13.14). If a
+ representation item {or aspect_specification} is given that directly
+ specifies an aspect of an entity, then it is illegal to give another
+ representation item {or aspect_specification} that directly specifies
+ the same aspect of the entity.
+
+ An operational item that directly specifies an aspect of a type shall
+ appear before the type is frozen (see 13.14). If an operational item
+ is given that directly specifies an aspect of a type, then it is
+ illegal to give another operational item {or aspect_specification}
+ that directly specifies the same aspect of the type.
+
Revise 13.3(5/1) as follows:
... Each specifiable attribute constitutes an operational aspect or
@@ -367,15 +383,19 @@
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. The expected type for the name
- is the type of the identified aspect of the associated entity.
+ name; the expected type for the name
+ is the type of the identified aspect of the associated entity;
+
* an aspect that is a value or an expression, the aspect_definition
- shall be an expression. The expected type for the expression
- is the type of the identified aspect of the associated entity.
+ shall be an expression; the expected type for the expression
+ is the type of the identified aspect of the associated entity;
+
* 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.
+ is the profile required for the aspect of the associated entity;
+
* an aspect 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.
@@ -385,17 +405,24 @@
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 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.
+ If the associated declaration is for a subprogram or entry, the names
+ of the formal parameters are directly 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 visible components, protected
+ subprograms, and entries are directly 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
+ If the freezing point of the associated entity comes before the end of
+ the immediately enclosing declaration list, then each usage name in the
+ aspect_definition shall resolve to the same entity at both places.
+
At most one occurrence of each aspect_mark is allowed within a single
aspect_specification. The aspect identified by the aspect_mark
shall be an aspect that can be specified for the associated entity.
@@ -407,12 +434,9 @@
If the aspect_mark includes 'Class, then the associated entity shall be
a tagged type or the primitive subprogram of a tagged type.
- 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
+ Depending on which aspect is 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
@@ -428,12 +452,24 @@
the specification applies to the corresponding primitive subprogram of
all descendants of T.
+ All specifiable operational and representation attributes may be
+ specified with an aspect_specification instead of an
+ attribute_definition_clause (see 13.3). The attribute_designator is
+ used for the aspect_mark. In addition, other operational and
+ representation aspects not associated with specifiable attributes may
+ be specified, as specified elsewhere in this International Standard.
+ In the case of aspects specifiable with pragmas, the pragma identifier
+ is used for the aspect_mark.
+
+ Alternative legality and semantics rules may apply for particular
+ aspects, as specified elsewhere in this International Standard.
+
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 name or expression, unless the aspect itself is an
- expression. If the corresponding aspect represents an expression (as in a
+ 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.
@@ -497,6 +533,49 @@
would be names such as "Inherited_Pre", but Pre'Class meaning it applies
to T'Class seems more natural.
+We defer resolving the names in the aspect_definition to the first
+freezing point or end of the declaration list because in many cases the
+entities referenced in the aspect_definition will necessarily, or more
+conveniently, be declared after the entity with the aspect
+specification. For example, for a type, any aspect that refers to an
+operation of the type will be a forward reference. For a subprogram, an
+aspect that refers to another subprogram will often be a forward
+reference, as ordering the subprograms based on the aspect_definitions
+would be painful and sometimes impossible.
+
+If the freezing point comes before the end of the enclosing declaration
+list, we require the usage names in the aspect_definition to resolve to
+the same entities at the two places. Because there is no explicit
+indication of where a freezing point occurs in the source, we felt it
+would be too confusing if we didn't require this. This means that if a
+freezing point "moves" and thereby crosses over, for example, the
+overriding of an inherited subprogram (of a non-tagged type), the
+compiler would complain rather than silently reinterpreting the name in
+the aspect_definition. For example:
+
+ type New_T is new T
+ with Type_Invariant => Is_Valid(New_T);
+
+ Default_Obj : New_T; -- Here we freeze New_T
+
+ function Is_Valid(Y : New_T) return Boolean;
+ -- Here we override Is_Valid
+
+ private -- Here we reach the end of the declaration list.
+
+In a case like this, the user almost certainly wants to refer to the
+overriding of Is_Valid, but since the freezing happens before the
+overriding, without the rule to require that the names in the
+aspect_definition resolve to the same thing, they would not get what
+they expected. With this rule, the compiler would complain, and the
+user would (hopefully ;-) realize they need to move the declaration of
+Default_Obj down a little further so Is_Valid can be overridden first.
+
+We don't bother talking about the case of a declaration with multiple
+defining_identifiers in its defining_identifier_list, because RM
+3.3.1(7) already says such a multi-defining-identifier declaration is
+equivalent to a sequence of single-defining-identifier declarations.
+
Much of the semantics is left to the particular aspects, as it is hard
to talk about such things in a general way.
@@ -637,7 +716,7 @@
@drepl
@xcode<@fa<task_type_declaration ::=
- >@b<@ft<task type>>@fa< defining_identifier [known_discriminant_part] [>@b<@ft<is>>@fa<
+ >@b<@ft<task type>>@fa< defining_identifier [known_discriminant_part] [>@b<@ft<is>>@fa<
[>@b<@ft<new>>@fa< interface_list >@b<@ft<with>>@fa<]
task_definition];>>
@dby
@@ -651,7 +730,7 @@
@drepl
@xcode<@fa<single_task_declaration ::=
- >@b<@ft<task>>@fa< defining_identifier [>@b<@ft<is>>@fa<
+ >@b<@ft<task>>@fa< defining_identifier [>@b<@ft<is>>@fa<
[>@b<@ft<new>>@fa< interface_list >@b<@ft<with>>@fa<]
task_definition];>>
@dby
@@ -665,7 +744,7 @@
@drepl
@xcode<@fa<protected_type_declaration ::=
- >@b<@ft<protected type>>@fa< defining_identifier [known_discriminant_part] >@b<@ft<is>>@fa<
+ >@b<@ft<protected type>>@fa< defining_identifier [known_discriminant_part] >@b<@ft<is>>@fa<
[>@b<@ft<new>>@fa< interface_list >@b<@ft<with>>@fa<]
protected_definition;>>
@dby
@@ -679,7 +758,7 @@
@drepl
@xcode<@fa<single_protected_declaration ::=
- >@b<@ft<protected>>@fa< defining_identifier >@b<@ft<is>>@fa<
+ >@b<@ft<protected>>@fa< defining_identifier >@b<@ft<is>>@fa<
[>@b<@ft<new>>@fa< interface_list >@b<@ft<with>>@fa<]
protected_definition;>>
@dby
@@ -1586,6 +1665,129 @@
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.)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, October 25, 2010 2:55 PM
+
+Here is a relatively minor update to AI05-0183-1. [This is version /06 of
+the AI.]
+
+I added a requirement that all usage_names that appear in an aspect_definition
+resolve to the same thing if freezing happens before the end of the declaration
+list, along with an example in the !discussion.
+
+I added some general statements about attribute-defs and pragmas that can be
+replaced by aspect_specs.
+
+I made some other minor fixes as requested in the minutes.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, October 25, 2010 3:13 PM
+
+> If the freezing point comes before the end of the enclosing
+> declaration list, we require the usage names in the aspect_definition
+> to resolve to the same entities at the two places. Because there is
+> no explicit indication of where a freezing point occurs in the source,
+> we felt it would be too confusing if we didn't require this.
+
+I really have NO idea how to implement this without a major earthquake.
+I think we will just leave this unimplemented in GNAT and not bother with it. At
+this stage ACATS tests are merely useful tools anway, formal validation has
+entirely disappeared as an issue.
+
+Perhaps Ed has some ideas.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, October 25, 2010 3:19 PM
+
+Did you take a look at the example in the !discussion?
+It does seem pretty convincing (at least to me) that this is a legitimate
+concern. Here it is again.
+
+===
+
+If the freezing point comes before the end of the enclosing declaration list, we
+require the usage names in the aspect_definition to resolve to the same entities
+at the two places. Because there is no explicit indication of where a freezing
+point occurs in the source, we felt it would be too confusing if we didn't
+require this. This means that if a freezing point "moves" and thereby crosses
+over, for example, the overriding of an inherited subprogram (of a non-tagged
+type), the compiler would complain rather than silently reinterpreting the name
+in the aspect_definition. For example:
+
+ type New_T is new T
+ with Type_Invariant => Is_Valid(New_T);
+
+ Default_Obj : New_T; -- Here we freeze New_T
+
+ function Is_Valid(Y : New_T) return Boolean;
+ -- Here we override Is_Valid
+
+ private -- Here we reach the end of the declaration list.
+
+In a case like this, the user almost certainly wants to refer to the overriding
+of Is_Valid, but since the freezing happens before the overriding, without the
+rule to require that the names in the aspect_definition resolve to the same
+thing, they would not get what they expected. With this rule, the compiler
+would complain, and the user would (hopefully ;-) realize they need to move the
+declaration of Default_Obj down a little further so Is_Valid can be overridden
+first.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, October 25, 2010 3:54 PM
+
+Are these things really called Type_Invariant, rather than just Invariant? I
+don't really mind, but it is a pain to change and I prefer the shorter name
+anyway.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, October 25, 2010 3:55 PM
+
+> Did you take a look at the example in the !discussion?
+> It does seem pretty convincing (at least to me) that this is a
+> legitimate concern. Here it is again.
+
+I think whenever you cause a major impossible pain to an existing implementation
+(Ed agrees with me that this is that category), then you have to be sure it is
+worth it. To recall, for Ada 95, we went out of our way to accomodate displays
+because one implementation demanded it, despite the fact that it
+
+a) really damaged expressive power
+
+b) turned out to be quite unnecessary, the one implementation involved never
+ made it to Ada 95 anyway.
+
+I don't think this begins to be in the category of critical things that are
+worth causing major pain to an implementation (especially considering that you
+can't really do that any more, implementations will just ignore things they
+can't implement, especially when it is just a matter of diagnosing unexpected
+behavior).
+
+To me this is more in the warning category anyway I would just settle for
+implementation advice that says it is desirable to warn in this situation.
+
+Yes, I see the example, but as I say, it is more a case where a warning is more
+appropriate anyway, I am always nervous when I see a language designer say
+
+"the user almost certainly wants to ..."
+
+which is more likely worth a warning if true.
+
+In this case, what GNAT could do, and actually it seems a good idea, is to have
+optional information messages that say
+
+ "warning: Invariant expression from line 12 is resolved here"
+ "warning: since type& is frozen here"
****************************************************************
Questions? Ask the ACAA Technical Agent