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

Differences between 1.4 and version 1.5
Log of other versions for file 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