CVS difference for ai05s/ai05-0215-1.txt
--- ai05s/ai05-0215-1.txt 2011/03/17 04:10:58 1.4
+++ ai05s/ai05-0215-1.txt 2011/03/17 04:37:40 1.5
@@ -1,4 +1,4 @@
-!standard 9.5(10-18/3) 11-03-16 AI05-0215-1/02
+!standard 9.5(10-18/3) 11-03-17 AI05-0215-1/03
!standard 9.5.4(3/3)
!standard 9.5.4(5/3)
!standard 9.5.4(5.1/3)
@@ -77,7 +77,16 @@
same Synchronization_Kind, or the inherited Synchronization_Kind shall be
By_Any.
+Modify 9.5(18/3) as follows:
+ [A pragma Implemented is said to *apply* to the procedure denoted
+ by its *procedure_*local_name.] {Inherited subprograms inherit the
+ Implemented aspect, if any, from the corresponding subprogram of the
+ parent or progenitor type.} If an overriding operation does not have
+ a [pragma] {directly specified} Implemented {aspect} then [any pragma
+ Implemented applying to] {Implemented aspect of} the inherited
+ operation [applies to] {is inherited by} the overriding operation.
+
Modify 9.5.4(3/3) as follows:
The *procedure_or_entry_*name of a requeue_statement shall resolve to
@@ -100,9 +109,9 @@
entry, or shall denote {a view or} a prefixed view of a primitive
subprogram of a synchronized interface, where the first parameter of
the unprefixed view of the primitive subprogram shall be a controlling
- parameter, and [an] {the} Is_Synchronized [pragma] {aspect shall be
- specified} with Synchronization_Kind By_Entry [shall apply to] {for}
- the primitive subprogram.
+ parameter, and [an Implemented pragma] {the Is_Synchronized aspect shall be
+ specified} with [implementation_kind]{Synchronization_Kind} By_Entry [shall
+ apply to] {for} the primitive subprogram.
!discussion
@@ -426,6 +435,156 @@
version of the AI to annex J.
[This is version /02 of the AI - Editor.]
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, March 16, 2011 4:06 PM
+
+Can't say I love "Is_Synchronized => By_Any"
+Doesn't make a whole lot of sense to me.
+"Yes" or "True" would read better, IMHO.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Wednesday, March 16, 2011 4:14 PM
+
+"True" seems confusing because this is not a boolean aspect. I guess
+Is_Synchronized => Yes is acceptable, to indicate that some subsequent
+overriding operation will be a legal target of a requeue operation.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, March 16, 2011 5:01 PM
+
+> I did not see the need to have an additional value to specify a
+> default, = given the stated inheritance rules.
+
+OK.
+
+> I guess Bob will move the skeleton of the previous version of the AI
+> to = annex J.
+
+I think that's Randy's job.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, March 16, 2011 9:46 PM
+
+> I guess Bob will move the skeleton of the previous version of the AI
+> to annex J.
+
+I thought that we were not even going to define a pragma for this one (unlike
+CPU). Pragmas are nasty for subprograms, and these are subprograms. So no need
+to put anything in Annex J.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, March 16, 2011 9:53 PM
+
+> Can't say I love "Is_Synchronized => By_Any"
+> Doesn't make a whole lot of sense to me.
+> "Yes" or "True" would read better, IMHO.
+
+Except that it really means that it is not necessarily synchronized (it can be a
+normal subprogram, which is not synchronized by any imagination), so it is more
+like "Maybe_Not".
+
+ Is_Synchronized => Maybe_Not
+
+Perfect. ;-)
+
+ Is_Synchronized => Probably_Not
+
+ Is_Synchronized => Hardly_Ever
+
+ Is_Synchronized => Not_Specified
+
+(but specifying something to be Not_Specified seems like a tautology :-)
+
+ Is_Synchronized => Not_Required
+
+ Is_Synchronized => Not_Necessarily_Synchronized
+
+Fill in your own ideas here.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, March 16, 2011 10:14 PM
+
+> Here is an aspect-centric version of this AI.
+
+Your version seem to have lost the revised 9.5(18/3) that defined the
+inheritance of the aspects. (This was part of the fixes of this AI, not
+something that previously existed - there are no rules in the Standard that
+described inheritance for aspects of subprograms - of course, Tucker might be
+writing those as I write this.) Anyway, I put it back, pending whatever Tucker
+does in 13.1.
+
+Modify 9.5(18/3):
+
+ [A pragma Implemented is said to *apply* to the procedure denoted
+ by its *procedure_*local_name.] {Inherited subprograms inherit the
+ Implemented aspect, if any, from the corresponding subprogram of the
+ parent or progenitor type.} If an overriding operation does not have
+ a [pragma] {directly specified} Implemented {aspect} then [any pragma
+ Implemented applying to] {Implemented aspect of} the inherited
+ operation [applies to] {is inherited by} the overriding operation.
+
+The last paragraph doesn't mark the changes properly (since
+"implementation-kind" and "Implemented" were changed without markings):
+
+Modify 9.5.4(5.1/3):
+
+ If the target is a procedure, the name shall denote a rename of an
+ entry, or shall denote {a view or} a prefixed view of a primitive
+ subprogram of a synchronized interface, where the first parameter of
+ the unprefixed view of the primitive subprogram shall be a controlling
+ parameter, and [an Implemented pragma] {the Is_Synchronized aspect shall be
+ specified} with [implementation_kind]{Synchronization_Kind} By_Entry [shall
+ apply to] {for} the primitive subprogram.
+
+I've corrected the AI with these changes.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Wednesday, March 16, 2011 10:20 PM
+
+> Your version seem to have lost the revised 9.5(18/3) that defined the
+> inheritance of the aspects. (This was part of the fixes of this AI,
+> not something that previously existed - there are no rules in the
+> Standard that described inheritance for aspects of subprograms
+
+I thought (naively no doubt) that the rules for pre- and post-conditions are
+precisely inheritance rules for aspects of subprograms.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, March 16, 2011 10:33 PM
+
+...
+> > Your version seem to have lost the revised 9.5(18/3) that defined
+> > the inheritance of the aspects. (This was part of the fixes of this
+> > AI, not something that previously existed - there are no rules in
+> > the Standard that described inheritance for aspects of subprograms
+>
+> I thought (naively no doubt) that the rules for pre- and
+> post-conditions are precisely inheritance rules for aspects of
+> subprograms.
+
+I don't think Pre or Post are inherited at all. There is a rule for Pre'Class
+and Post'Class (13.3.2(10/3)) that specifically defines that they "apply" to
+descendants, but formally they aren't inherited either (which is why you can
+give a new one for them on the descendant).
+
+So that isn't much help. ;-)
****************************************************************
Questions? Ask the ACAA Technical Agent