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

Differences between 1.8 and version 1.9
Log of other versions for file ai05s/ai05-0215-1.txt

--- ai05s/ai05-0215-1.txt	2011/04/07 06:30:24	1.8
+++ ai05s/ai05-0215-1.txt	2011/04/08 02:20:59	1.9
@@ -1,8 +1,9 @@
-!standard  9.5(10-18/3)                            11-04-06    AI05-0215-1/06
+!standard  9.5(10-18/3)                            11-04-07    AI05-0215-1/07
 !standard  9.5.4(3/3)
 !standard  9.5.4(5/3)
 !standard  9.5.4(5.1/3)
 !class binding interpretation 10-06-12
+!status ARG Approved  6-0-2  10-04-07
 !status work item 10-06-12
 !status received 10-03-26
 !priority Low
@@ -70,9 +71,11 @@
   a primitive procedure of a task interface.
 
   A procedure for which the specified Synchronization_Kind is By_Entry shall
-  be implemented by a an entry. A procedure for which the
-  specified  Synchronization_Kind is as By_Protected_Procedure shall be
-  implemented by a protected procedure.
+  be implemented by an entry. A procedure for which the
+  specified Synchronization_Kind is By_Protected_Procedure shall be
+  implemented by a protected procedure. A procedure for which the specified
+  Synchronization_Kind is Optional may be implemented by an entry or by
+  a procedure (including a protected procedure).
 
   If a primitive procedure overrides an inherited operation for which the
   Is_Synchronized aspect has been specified, then any specification of the
@@ -756,6 +759,75 @@
 majority say "renaming of", and personally I think the latter sounds better.  I
 suppose all the various instances of this wording should be made consistent.  (I'll
 understand if you choose to simply ignore this suggestion. :)
+
+****************************************************************
+
+From: John Barnes
+Sent: Thursday, April 7, 2011  6:20 AM
+
+In the following note some typos
+
+Modify 9.5(13/3 - 16/3) as follows:
+
+
+  For the declaration of a primitive procedure of a synchronized tagged type
+  the following language-defined representation aspect may be specified with
+  an aspect_specification:
+    Is_Synchronized.
+      If specified, the aspect definition shall be a Synchronization_Kind.
+
+  The Synchronization_Kind By_Protected_Procedure shall not be applied to
+  a primitive procedure of a task interface.
+
+  A procedure for which the specified Synchronization_Kind is By_Entry shall
+  be implemented by [a] an entry. A procedure for which the
+  specified  Synchronization_Kind is [as] By_Protected_Procedure shall be
+  implemented by a protected procedure.
+
+  If a primitive procedure overrides an inherited operation for which the
+  Is_Synchronized aspect has been specified, then any specification of the
+  aspect Is_Synchronized applied to the overriding operation shall have the
+  same Synchronization_Kind, or the inherited Synchronization_Kind shall be
+  Optional.
+
+
+For completeness in the para starting "A procedure" in the above. I would add
+something about the poor lonely Optional. eg
+
+A procedure for which the the specified Synchronization_Kind is Optional can 
+be implemented by an entry or by a procedure (including a protected 
+procedure).
+
+Maybe it is somthing to do with the battle of Agincourt but I don't like 
+Optional but much prefer By_Any.  It just has to start By_
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, April 7, 2011  9:20 PM
+
+...
+> Modify 9.5(13/3 - 16/3) as follows:
+...
+>   A procedure for which the specified Synchronization_Kind is By_Entry shall
+>   be implemented by [a] an entry. A procedure for which the
+>   specified  Synchronization_Kind is [as] By_Protected_Procedure shall be
+>   implemented by a protected procedure.
+...
+> For completeness in the para starting "A procedure" in the above. I 
+> would add something about the poor lonely Optional. eg
+> 
+> A procedure for which the the specified Synchronization_Kind is 
+> Optional can be implemented by an entry or by a procedure (including a
+> protected procedure).
+
+This is a fine idea, but "can" is not allowed in International Standards (by the
+drafting rules). We have to use "may" here.
+
+We can use "may", but may not use "can". Similarly, we must use "shall", we shall
+not use "must". But we cannot use "may not", and we may not use "cannot".
+
+Easy to remember, right? ;-)
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent