CVS difference for ai05s/ai05-0183-1.txt

Differences between 1.24 and version 1.25
Log of other versions for file ai05s/ai05-0183-1.txt

--- ai05s/ai05-0183-1.txt	2011/04/01 07:33:58	1.24
+++ ai05s/ai05-0183-1.txt	2011/04/02 07:14:42	1.25
@@ -1,4 +1,4 @@
-!standard 3.2.1(3)                                 11-03-30  AI05-0183-1/10
+!standard 3.2.1(3)                                 11-04-01  AI05-0183-1/11
 !standard 3.2.2(2)
 !standard 3.3.1(2/2)
 !standard 3.8(6)
@@ -393,16 +393,6 @@
   illegal to give another operational item {or aspect_specification}
   that directly specifies the same aspect of the [type]{entity}.
 
-Modify 13.1(11/2) as follows:
-
-  Operational and representation aspects of a generic formal parameter
-  are the same as those of the actual. [Operational and
-  r]{R}epresentation aspects are the same for all views of a type. {If
-  an operational aspect is specified for a partial view of a type, then
-  it applies to the full view as well.} A type-related representation
-  item is not allowed for a descendant of a generic formal untagged
-  type.
-
 Modify 13.1(15.1/2) as follows:
 
   In contrast, whether operational aspects are inherited by a[n
@@ -611,9 +601,41 @@
   overridden to have the value False for the derived type, unless
   otherwise specified in this International Standard.
 
+  If a Legality Rule or Static Semantics rule only applies when a particular
+  aspect has been specified, the aspect is considered to have been specified
+  only when the aspect_specification or attribute_definition_clause
+  is visible (see 8.3) at the point of the application of the rule.
+
+    AARM Reason: Some rules only apply when an aspect has been specified (for
+    instance, an indexable type is one that has aspect Variable_Indexing
+    specified). In order to prevent privacy breaking, this can only be true when
+    the specification of the aspect is visible. In particular, if the
+    Variable_Indexing aspect is specified on the full view of a private type,
+    the private type is not considered an indexable type.
+
   There are no language-defined aspects that may be specified on a
   renaming_declaration nor on a formal_type_declaration.
 
+    AARM Discussion: Implementation-defined aspects can be allowed on these, of
+    course; the implementation will need to define the semantics. In particular,
+    the implementation will need to define actual type matching rules for any
+    aspects allowed on formal types; there are no default matching rules defined
+    by the language.
+
+  An aspect shall not be specified in an aspect_specification given on a
+  subprogram_body that is a completion of another declaration.
+
+    AARM Reason: Most aspects (for example, preconditions) are intended to be
+    available to callers, and specifying them on a body that has a separate
+    declaration hides them from callers. Specific aspects (both language-defined
+    and implementation-defined) may allow this, but they have to do so
+    explicitly (by appealing the following rule or the Implementation
+    Permission), and provide any needed rules about visibility.
+
+    [Note: We write this in terms of specifying an aspect, rather than simply
+    saying that an aspect_specification is not allowed, so that specific
+    aspects can allow this.]
+
   Alternative legality and semantics rules may apply for particular
   aspects, as specified elsewhere in this International Standard.
 
@@ -635,7 +657,7 @@
   follow implementation-defined legality and semantics rules.
 
     AARM Discussion: The intent is to allow implementations to support
-    aspects which are defined, for example, by a subtype_indication
+    aspects that are defined, for example, by a subtype_indication
     rather than an expression or a name.  We chose not to try to
     enumerate all possible aspect_definition syntaxes, but to give
     implementations maximum freedom, at least in this version of the
@@ -769,9 +791,7 @@
 
 Much of the semantics is left to the particular aspects, as it is hard
 to talk about such things in a general way. Implementations are permitted
-maximum freedom in defining their own aspects. It is possible that a
-future standard might specify some limitations, but it seems premature
-to do so at this stage.
+maximum freedom in defining their own aspects.
 
 !corrigendum 3.2.1(3)
 
@@ -1238,21 +1258,6 @@
 illegal to give another operational item or @fa<aspect_specification>
 that directly specifies the same aspect of the entity.
 
-!corrigendum 13.1(11/2)
-
-@drepl
-Operational and representation aspects of a generic formal parameter are the
-same as those of the actual. Operational and representation aspects are the
-same for all views of a type. A type-related representation item is not allowed
-for a descendant of a generic formal untagged type.
-@dby
-Operational and representation aspects of a generic formal parameter
-are the same as those of the actual. Representation aspects are the same
-for all views of a type. If an operational aspect is specified for a partial
-view of a type, then it applies to the full view as well. A type-related
-representation item is not allowed for a descendant of a generic formal untagged
-type.
-
 !corrigendum 13.1(15.1/2)
 
 @drepl
@@ -1436,9 +1441,17 @@
 overridden to have the value False for the derived type, unless
 otherwise specified in this International Standard.
 
+If a Legality Rule or Static Semantics rule only applies when a particular
+aspect has been specified, the aspect is considered to have been specified
+only when the @fa<aspect_specification> or @fa<attribute_definition_clause>
+is visible (see 8.3) at the point of the application of the rule.
+
 There are no language-defined aspects that may be specified on a
 @fa<renaming_declaration> nor on a @fa<formal_type_declaration>.
 
+An aspect shall not be specified in an @fa<aspect_specification> given on a
+@fa<subprogram_body> that is a completion of another declaration.
+
 Alternative legality and semantics rules may apply for particular
 aspects, as specified elsewhere in this International Standard.
 
@@ -6477,10 +6490,231 @@
     would make some AdaCore thing illegal, but it isn't so clear about some
     second-tier vendor in Wisconsin. That note seems to discourage using the
     permission, which seems wrong to me -- if we don't think it is good idea, we
-    wouldn't do it at all. So I suggest that we just drop that part.
+    shouldn't do it at all. So I suggest that we just drop that part.
 
 
 You can just send me any needed wording changes; I don't want to get the whole
 AI again!
+
+****************************************************************                                                                                                                                                                                               
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                     implementing semantic features.
+
+From: Robert Dewar
+Sent: Friday, April  1, 2011  7:08 AM
+
+> (1) I didn't see a Legality Rule to prevent the specification of
+> aspects on a subprogram_body unless there is no separate
+> subprogram_specification. I don't think we want (heck, I *know* we
+> don't want) hidden aspects (only known to the body). A hidden Pre'Class aspect
+> would blow up everything.
+> There is an "out" to allow deviations from the normal rules - so a
+> particular aspect could allow hidden versions if it wanted them, so I
+> think a blanket rule banning them is fine (and preferred).
+
+This limitation should not affect implementation defined aspects
+
+> (3) [and least] I'm dubious about the "at least in this version" part
+> of the AARM note of the Implementation Permission. That seems to say
+> "If we don't like what you guys are doing with this toy (the
+> permission), we'll take it away at our next chance!! Nah-nah!!". I
+> can't imagine that a future ARG would make some AdaCore thing illegal,
+> but it isn't so clear about some second-tier vendor in Wisconsin.
+
+Yes it is, even if the ARG were to make such a (peculiar and
+ill-advised) decision, the WG9 would never stand for it. In practice gratuitous
+non upwards-compatible changes will never get through (that's why the whole
+Annex J thing is unnecessary, none of these features will ever be actually
+removed).
+
+> That note seems to discourage using the permission, which seems wrong
+> to me -- if we don't think it is good idea, we shouldn't do it at all.
+> So I suggest that we just drop that part.
+
+I agree with this recommendation
+
+****************************************************************                                                                                                                                                                                               
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                     implementing semantic features.
+
+From: Randy Brukardt
+Sent: Friday, April  1, 2011  1:34 PM
+
+> This limitation should not affect implementation defined aspects
+
+I disagree. The default ought to be "no hidden aspects", as those bring up all
+kinds of problems. Besides, this is similar to the way that we handled aspects
+in renames and aspects for generic formal parameters (and for similar reasons);
+they're not allowed by default.
+
+In all of these cases, an implementation can define an aspect that is allowed in
+these contexts. But they have to do so explicitly, which demonstrates that the
+implementer has thought about the ramifications of allowing that and presumably
+applied appropriate rules. We're not going to provide any such rules, so it is
+important that the implementer provide them somehow.
+
+It would be bad to allow "hidden aspects" without any framework for what they
+mean.
+
+Since the new Implementation Permission allows an implementation-defined aspect
+to work in any way that it wants (including syntax), this doesn't constrain
+implementation-defined aspects at all, just makes it clear that you are on your
+own if you want to use those.
+
+****************************************************************                                                                                                                                                                                               
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                     implementing semantic features.
+
+From: Robert Dewar
+Sent: Friday, April  1, 2011  2:19 PM
+
+> In all of these cases, an implementation can define an aspect that is
+> allowed in these contexts. But they have to do so explicitly, which
+> demonstrates that the implementer has thought about the ramifications
+> of allowing that and presumably applied appropriate rules. We're not
+> going to provide any such rules, so it is important that the
+> implementer provide them somehow.
+
+We agree then, that's all I am asking for, I think your viewpoint is entirely
+reasonable.
+
+> It would be bad to allow "hidden aspects" without any framework for
+> what they mean.
+>
+> Since the new Implementation Permission allows an
+> implementation-defined aspect to work in any way that it wants
+> (including syntax), this doesn't constrain implementation-defined
+> aspects at all, just makes it clear that you are on your own if you want to
+> use those.
+
+OK, that's fine, especially since the syntax already shows how these aspects
+would be spelled if they are added (it's a static semantic rule, not a syntax
+rule that forbids them if a separate spec is present).
+
+****************************************************************                                                                                                                                                                                               
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                     implementing semantic features.
+
+From: Bob Duff
+Sent: Friday, April  1, 2011  5:10 PM
+
+> Here is an update to the aspect_specification AI ...
+
+> !standard 3.2.1(3)                                 11-03-30  AI05-0183-1/10
+
+>     AARM Discussion: The intent is to allow implementations to support
+>     aspects which are defined, for example, by a subtype_indication
+
+"which" --> "that"
+
+****************************************************************                                                                                                                                                                                               
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                     implementing semantic features.
+
+From: Bob Duff
+Sent: Friday, April  1, 2011  5:29 PM
+
+> April Fool! :-)
+
+There's a lot of that going around today...
+
+> (3) [and least] I'm dubious about the "at least in this version" part
+> of the AARM note of the Implementation Permission. That seems to say
+> "If we don't like what you guys are doing with this toy (the
+> permission), we'll take it away at our next chance!! Nah-nah!!". I
+> can't imagine that a future ARG would make some AdaCore thing illegal,
+> but it isn't so clear about some second-tier vendor in Wisconsin. That
+> note seems to discourage using the permission, which seems wrong to me
+> -- if we don't think it is good idea, we shouldn't do it at all. So I
+> suggest that we just drop that part.
+
+I agree with the above paragraph 100%.  If we give this permission now, we mean
+it forever and ever, for all Ada implementations.
+
+(And we SHOULD give that permission:  Implementation defined things are
+implementation defined!  It almost goes without saying.)
+
+I also suggest you delete the last sentence of the !discussion:
+
+    ...It is possible that a future standard might specify some limitations,
+    but it seems premature to do so at this stage.
+
+If we're worried that people will worry that people will go hog-wild with
+aspects, then we should mention the No_Impl_Aspects restriction, which is in
+some other AI, which should assuage such worries.
+
+****************************************************************                                                                                                                                                                                               
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                     implementing semantic features.
+
+From: Tucker Taft
+Sent: Friday, April  1, 2011  10:25 PM
+
+I get the message.  What I was really trying to say was that we were too lazy to
+define an extensible syntax at this point, so we are just saying "anything
+goes." I thought in some later standard, based on experience, we might come up
+with a more "standard" extensible syntax.  But that is probably silly, and I
+certainly failed miserably in trying to communicate what I meant.
+
+****************************************************************                                                                                                                                                                                               
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                     implementing semantic features.
+
+From: Randy Brukardt
+Sent: Saturday, April  2, 2011  1:14 AM
+
+Since I haven't heard from Tucker, and the deadline is long past, I finished up
+the open issues here myself.
+
+I wrote:
+> (1) I didn't see a Legality Rule to prevent the specification of
+> aspects on a subprogram_body unless there is no separate
+> subprogram_specification. I don't think we want (heck, I
+> *know* we don't want) hidden aspects (only known to the body). A
+> hidden Pre'Class aspect would blow up everything.
+> There is an "out" to allow deviations from the normal rules - so a
+> particular aspect could allow hidden versions if it wanted them, so I
+> think a blanket rule banning them is fine (and preferred).
+
+I added the following to the Static Semantics:
+
+  An aspect shall not be specified in an aspect_specification given on a
+  subprogram_body that is a completion of another declaration.
+
+    AARM Reason: Most aspects (for example, preconditions) are intended to be
+    available to callers, and specifying them on a body that has a separate
+    declaration hides them from callers. Specific aspects (both language-defined
+    and implementation-defined) may allow this, but they have to do so
+    explicitly (by appealing the following rule or the Implementation
+    Permission), and provide any needed rules about visibility.
+
+    [Note: We write this in terms of specifying an aspect, rather than simply
+    saying that an aspect_specification is not allowed, so that specific
+    aspects can allow this.]
+
+The next rule is: "Alternative legality and semantics rules may apply for
+particular aspects, as specified elsewhere in this International Standard." This
+would make more sense as a Legality Rule, but since it is closely related to the
+formal_parameter and renames rule, I put it next to it.
+
+> (2) You didn't back out the botched changes to operational aspects
+> that we discussed last week on the ARG list. I thought that we were
+> going to define some sort of rule that defined when an aspect can be
+> considered "specified"
+> based on visibility, and eliminate most [not all] of the
+> (other??) 13.1 changes. Particularly 13.1(15). Aspects always exist
+> for types!
+
+I meant 13.1(11/2) above. We remove the changes to that paragraph, then add a
+rule to explain visibility of aspect specifications. This is not my best work,
+but this is what I came up with:
+
+Add to the Static Semantics:
+
+If a Legality Rule or Static Semantics rule only applies when a particular
+aspect has been specified, the aspect is considered to have been specified only
+when the aspect_specification or attribute_definition_clause is visible (see
+8.3) at the point of the application of the rule.
+
+AARM Reason: Some rules only apply when an aspect has been specified (for
+instance, an indexable type is one that has aspect Variable_Indexing specified).
+In order to prevent privacy breaking, this can only be true when the
+specification of the aspect is visible. In particular, if the Variable_Indexing
+aspect is specified on the full view of a private type, the private type is not
+considered an indexable type.
+
+[This is referring to 8.3(23.1/3), which defines the visibility of an
+aspect_specification or attribute_definition_clause. We don't need to define
+this for pragmas; these all control run-time effects.
+
+I defined this in this way so that I didn't need to introduce a new term and
+then find and change all of the associated uses. But perhaps a new term would be
+better given that "specified" already has a meaning for aspects (see 13.1).]
 
 ****************************************************************                                                                                                                                                                                               
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                     implementing semantic features.

Questions? Ask the ACAA Technical Agent