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

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

--- ai05s/ai05-0183-1.txt	2011/03/25 02:17:54	1.23
+++ ai05s/ai05-0183-1.txt	2011/04/01 07:33:58	1.24
@@ -1,9 +1,10 @@
-!standard 3.2.1(3)                                 11-03-16  AI05-0183-1/09
+!standard 3.2.1(3)                                 11-03-30  AI05-0183-1/10
 !standard 3.2.2(2)
 !standard 3.3.1(2/2)
 !standard 3.8(6)
 !standard 3.9.3(1.1/2)
 !standard 6.1(2/2)
+!standard 6.3(2/2)
 !standard 6.7(2/2)
 !standard 9.5.2(2/2)
 !standard 7.1(3)
@@ -40,6 +41,7 @@
 !standard 13.3.1(0)
 !standard 13.13.2(1/1)
 !standard 13.14(7.1/2)
+!standard 13.14(8/2)
 !class amendment 09-11-01
 !status Amendment 2012 10-09-01
 !status work item 10-11-19
@@ -91,6 +93,7 @@
     * subprogram_declaration;
     * abstract_subprogram_declaration;
     * null_procedure_declaration;
+    * subprogram_body;
     * package_declaration;
     * private_type_declaration;
     * private_extension_declaration;
@@ -168,6 +171,17 @@
     subprogram_specification
       [aspect_specification];
 
+Replace 6.3(2/2) by:
+
+  subprogram_body ::=
+    [overriding_indicator]
+    subprogram_specification
+      [aspect_specification] IS
+        declarative_part
+    BEGIN
+        handled_sequence_of_statements
+    END [designator];
+
 Replace 6.7(2/2) by:
 
   null_procedure_declaration ::=
@@ -613,6 +627,20 @@
   later at points within the execution as specified elsewhere in this
   International Standard for the particular aspect.
 
+          Implementation Permissions
+
+  Implementations may support implementation-defined aspects.  The
+  aspect_specification for an implementation-defined aspect may use an
+  implementation-defined syntax for the aspect_definition, and may
+  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
+    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
+    standard.
+
 Modify 13.13.2(1/1):
 
   The {type-related} operational attributes Write, Read, Output, and
@@ -623,7 +651,20 @@
 
 * At the freezing point of the entity associated with an aspect_specification,
   any expressions or names within the aspect_specification cause freezing.
+  Any static expressions within an aspect_specification also cause freezing
+  at the end of the immediately enclosing declaration list.
 
+Modify 13.14(8/3):
+
+  A static expression {(other than within an aspect_specification)}
+  causes freezing where it occurs.  An object name or nonstatic
+  expression causes freezing where it occurs, unless the name or
+  expression is part of a default_expression, a default_name, the
+  expression of an expression function{, an aspect_specification,} or a
+  per-object expression of a component's constraint, in which case, the
+  freezing occurs later as part of another construct {or at the freezing
+  point of an associated entity}.
+
 !discussion
 
 This syntax was invented to allow pre- and postconditions to be specified
@@ -727,7 +768,10 @@
 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.
+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.
 
 !corrigendum 3.2.1(3)
 
@@ -808,6 +852,26 @@
     subprogram_specification
       [aspect_specification];>>
 
+!corrigendum 6.3(2/2)
+
+@drepl
+@xcode<@fa<subprogram_body ::=
+   [overriding_indicator]
+   subprogram_specification >@ft<@b<is>>@fa<
+     declarative_part
+   >@ft<@b<begin>>@fa<
+      handled_sequence_of_statements
+   >@ft<@b<end>>@fa< [designator];>>
+@dby
+@xcode<@fa<subprogram_body ::=
+   [overriding_indicator]
+   subprogram_specification
+     [aspect_specification] >@ft<@b<is>>@fa<
+     declarative_part
+   >@ft<@b<begin>>@fa<
+      handled_sequence_of_statements
+   >@ft<@b<end>>@fa< [designator];>>
+
 !corrigendum 6.7(2/2)
 
 @drepl
@@ -1388,7 +1452,14 @@
 later at points within the execution as specified elsewhere in this
 International Standard for the particular aspect.
 
+@i<@s8<Implementation Permissions>>
+
+Implementations may support implementation-defined aspects. The
+@fa<aspect_specification> for an implementation-defined aspect may use an
+implementation-defined syntax for the @fa<aspect_definition>, and may
+follow implementation-defined legality and semantics rules.
 
+
 !corrigendum 13.13.2(1/1)
 
 @drepl
@@ -1401,13 +1472,33 @@
 !corrigendum 13.14(7.1/2)
 
 @dinsa
-@xbullet<The declaration of a record extension, interface type, task unit, or protected
-unit causes freezing of any progenitor types specified in the declaration.>
+@xbullet<The declaration of a record extension, interface type, task unit, or
+protected unit causes freezing of any progenitor types specified in the
+declaration.>
 @dinst
-@xbullet<At the freezing point of the entity associated with an @fa<aspect_specification>,
-any @fa<expression>s or @fa<name>s within the @fa<aspect_specification> cause freezing.>
+@xbullet<At the freezing point of the entity associated with an
+@fa<aspect_specification>, any @fa<expression>s or @fa<name>s within the
+@fa<aspect_specification> cause freezing. Any static expressions within an
+@fa<aspect_specification> also cause freezing at the end of the immediately
+enclosing declaration list.>
 
+!corrigendum 13.14(8/2)
 
+@drepl
+A static expression causes freezing where it occurs. An object name or nonstatic
+expression causes freezing where it occurs, unless the name or expression is
+part of a @fa<default_expression>, a @fa<default_name>, or a per-object
+expression of a component's @fa<constraint>, in which case, the freezing occurs
+later as part of another construct.
+@dby
+A static expression (other than within an @fa<aspect_specification>) causes
+freezing where it occurs. An object name or nonstatic expression causes freezing
+where it occurs, unless the name or expression is part of a
+@fa<default_expression>, a @fa<default_name>, an @fa<aspect_specification>, or a
+per-object expression of a component's @fa<constraint>, in which case, the
+freezing occurs later as part of another construct or at the freezing point of
+an associated entity.
+
 !example
 
 (See discussion.)
@@ -6195,5 +6286,201 @@
 
 Unless the intent is to change this for all type-related operational aspects --
 which is going too far IMHO.
+
+****************************************************************                                                                                                                                                                                               
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                     implementing semantic features.
+
+From: Tucker Taft
+Sent: Thursday, March 24, 2011  8:15 AM
+
+I'm not sure what we mean by the "value" of an aspect like this.
+These are dispatching routines, so there are really two things.
+One is the relevant declaration, and the other is the body actually invoked.
+For a non-limited type, there is the implicit declaration of the visible 'Read
+operation, and then possibly an overriding of the associated body in the private
+part.  For a limited type, there is generally no implicit declaration (unless it
+is defined on the parent type), and so the partial view really doesn't have the
+aspect at all.
+
+Clearly the body you end up calling is a run-time thing, and run-time things are
+always based on the full view of a type.  But the relevant declaration is what
+we worry about at compile-time, and in that case, they can be quite different
+between the full view and the partial view for operational aspects.
+
+On the other hand, for representational aspects, if you ask for the 'Size of the
+partial view, you will always get the same value as you get for the full view.
+So for representational aspects, it seems that the full view and the partial
+view are more in alignment.
+
+We could revert the wording to the prior definition, but I think we need to
+acknowledge that sometimes the partial view doesn't have the aspect at all.
+Perhaps we could say that if the aspect is defined for the partial view, it has
+the same run-time effect as that of the full view.  But it might not have the
+aspect at all, from a *static* semantics point of view.  I think it should go
+without saying that from a *dynamic* semantics point of view, all that matters
+is the full type.
+
+****************************************************************                                                                                                                                                                                               
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                     implementing semantic features.
+
+From: Randy Brukardt
+Sent: Thursday, March 24, 2011  7:43 PM
+
+> I'm not sure what we mean by the "value" of an aspect like this.
+
+Ah-ha, the crux of the problem.
+
+> These are dispatching routines, so there are really two things.
+> One is the relevant declaration, and the other is the body actually
+> invoked.  For a non-limited type, there is the implicit declaration of
+> the visible 'Read operation, and then possibly an overriding of the
+> associated body in the private part.  For a limited type, there is
+> generally no implicit declaration (unless it is defined on the parent
+> type), and so the partial view really doesn't have the aspect at all.
+>
+> Clearly the body you end up calling is a run-time thing, and run-time
+> things are always based on the full view of a type.
+> But the relevant declaration is what we worry about at compile-time,
+> and in that case, they can be quite different between the full view
+> and the partial view for operational aspects.
+
+No, this is not the view of operational aspects that I have, no wonder you (or
+I) are confused. We do not care "where these are declared", because they are
+language-defined and always exist.
+
+My understanding of the model of (existing Ada 2005) aspects is that the aspects
+always exist for every relevant entity. Every object has a Size aspect
+(attribute), whether or not it is specified. Similarly, every type has a Read
+aspect (attribute), whether or not it is specified. Since these things are
+attributes, the language defines their profile; the specified subprogram is
+irrelevant when it comes to calling one of them. For instance, you cannot use
+named notation in calling one of these (the parameters have no names), not
+matter what the actual is.
+
+In order to deal with the possibility that there is no useful value in some
+cases, we have the concept of availability. If the stream attribute is not
+available, then a call is illegal.
+
+That means that the "value" of an aspect is its runtime value. And it always
+exists. If you want to prevent accessing it in some cases, you need separate
+legality rules to do so. (And I think only stream attributes have such rules.)
+In some cases, the "value" is view-specific, and in other cases it is
+entity-specific -- but in all cases there is a value.
+
+
+I have always expected that this model carried over to the new aspects. That was
+the point of the big blow up about "view-specific" vs. "entity-specific"
+aspects. It's also why we've tried to define default values for aspects (like
+"Optional" for Is_Synchronized), so we don't have to worry about the cases where
+they are not specified at all. Generally, we've worked hard to avoid having
+things depend on whether or not something is specified, so that the default
+implementation-defined value works the same as a specified value.
+
+We do have cases where there is just no possible value to talk about
+(Default_Value comes to mind), and this is clearly new. But even that can be
+modeled properly: such an aspect is <empty> when it is not specified (which is
+different than unspecified!), and has a defined value in other cases.
+
+> On the other hand, for representational aspects, if you ask for the
+> 'Size of the partial view, you will always get the same value as you
+> get for the full view.  So for representational aspects, it seems that
+> the full view and the partial view are more in alignment.
+>
+> We could revert the wording to the prior definition, but I think we
+> need to acknowledge that sometimes the partial view doesn't have the
+> aspect at all.  Perhaps we could say that if the aspect is defined for
+> the partial view, it has the same run-time effect as that of the full
+> view.  But it might not have the aspect at all, from a *static*
+> semantics point of view.  I think it should go without saying that
+> from a
+> *dynamic* semantics point of view, all that matters is the full type.
+
+I don't believe there is any case where some view of an entity does not have an
+aspect; every entity has every aspect that is associated with that class of
+entity. If the aspect is view-specific, then some view might not be able to see
+that the aspect has a specified value. But if the aspect is entity-specific (and
+we agreed that type-related aspects are in this category), you have to add
+separate (Legality) rules for a particular aspect to handle that (as was done
+for stream attributes).
+
+
+If you really want to pursue a model where the aspect itself does not exist in
+some cases, then I think you would need to invent a new kind of aspect rather
+than reuse an existing one. ("Conditional aspects"?) But I don't think that
+there is much point; the current model seems to work fine.
+
+****************************************************************                                                                                                                                                                                               
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                     implementing semantic features.
+
+From: Tucker Taft
+Sent: Thursday, March 24, 2011  8:03 PM
+
+OK, I'm convinced.  But I still think we need to acknowledge that something
+about visibility or availability or whatever of an aspect specification might
+affect whether certain uses are permitted. But if the use is permitted, then I
+agree it shouldn't matter whether you are talking about the partial view or the
+full view.
+
+****************************************************************                                                                                                                                                                                               
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                     implementing semantic features.
+
+From: Randy Brukardt
+Sent: Thursday, March 24, 2011  8:37 PM
+
+Right. One possibility would be to expand the concept of "availability" to other
+aspects. But that has lots of other stuff tied up in it, so I suspect it is a
+bad idea.
+
+Probably a better idea is to formally define when an aspect is considered to
+have been specified (since that depends on visibility). If that's done, then the
+wording I've used ("If aspect Blah is specified, then ...") will work properly
+in the case of visibility. If you don't like "specified", pick another word. (I
+usually use "Muggywomp" as a placeholder for such cases; Steve uses "Frobisher".
+"If aspect Blah is Muggywomped, then ..." Perfect! :-)
+
+****************************************************************                                                                                                                                                                                               
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                     implementing semantic features.
+
+From: Tucker Taft
+Sent: Thursday, March 31, 2011  10:53 PM
+
+Here is an update to the aspect_specification AI which has some additional stuff
+about freezing as it relates to static expressions.  I also allowed
+aspect_specifications on subprogram bodies, and added an implementation
+permission which basically "anything goes" for the syntax and semantics of
+aspect_definitions for implementation-defined aspects.
+
+[Editor's note: The is version /10 of the AI.]
+
+****************************************************************                                                                                                                                                                                               
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                     implementing semantic features.
+
+From: Randy Brukardt
+Sent: Friday, April  1, 2011  1:32 AM
+
+Perfect!
+
+April Fool! :-)
+
+(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).
+
+(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!
+
+(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
+    wouldn'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.

Questions? Ask the ACAA Technical Agent