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

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

--- ai05s/ai05-0215-1.txt	2011/05/12 07:03:52	1.12
+++ ai05s/ai05-0215-1.txt	2011/06/20 04:55:18	1.13
@@ -4,6 +4,7 @@
 !standard  E.2.2(14)
 !class Amendment 11-04-28
 !status Amendment 2012 11-05-11
+!status ARG Approved (by Letter Ballot) 9-1-1  11-05-16
 !status work item 10-04-30
 !status ARG Approved  6-0-2  11-04-07
 !status work item 10-06-12
@@ -1618,3 +1619,171 @@
 
 ****************************************************************
 
+From: Erhard Ploedereder
+Sent: Sunday, May 15, 2011  11:31 AM
+
+[The appropriate part of a longer message - Editor]
+
+AI05-0215-1/08  Pragma Implemented should be an aspect, renamed, and better defined
+   [The class of this AI was wrong; it modifies an Amendment AI, so it also has to be Amendment.
+    Otherwise, it is unchanged.]
+   Approve ______ Disapprove __ X ____ Abstain _______
+
+============
+
+Why doesn't 9.5(18/3) simply say: "The Synchonization aspect is inherited by
+derived types." ?
+
+The current verbage is rather confusing, since the neded other part of it is in 16/3.
+Here is the draft of a(n erroneous) comment that I was led to by 18/3:
+------
+I am surprised that 9.5(18/3) seems to allow that By_Protected_Procedure can become
+By_Entry in a redefining declaration. Is this really intended, so that I call on a
+routine that promises no barrier and then the redefining routine does block after all?
+Not good!
+-------
+I know now that 16/3 prevents it, but why this completely convoluted way of saying
+"is an inheritable aspect"?
+
+I am unconfortable with the term "Optional" in this context after all, since
+"Synchronization = Optional" definitely reads as if synchronization were optional,
+which of course is completely contradictory to the restriction to protected operations.
+(To my shame, I was misled into a different semantics by the "Not_Required"
+as alternative in the poll, since I presumed that finally normal subprograms renaming
+entries could get this aspect to communicate their important synchronization property.
+Well, fooled me.)
+
+ "Synchronization_Kind =Optional" would be semi-ok.
+ "Synchronization =By_Any" sounds much better to me, now in context.
+
+The title of the AI should be made matching the content.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Monday, May 16, 2011  4:40 PM
+
+[The appropriate part of a longer message - Editor]
+
+> AI05-0215-1/08  Pragma Implemented should be an aspect, renamed, and
+> better defined
+>    [The class of this AI was wrong; it modifies an Amendment AI, so it
+> also has to be Amendment.
+>     Otherwise, it is unchanged.]
+>    Approve ______ Disapprove ______ Abstain __X____
+
+[Comment: I find myself tending to agree with Erhard's comment regarding
+Optional vs. By_Any, though not enough to vote for disapproval.
+
+ Erhard said:
+
+  I am unconfortable with the term "Optional" in this context after all,
+  since "Synchronization = Optional" definitely reads as if
+  synchronization were optional, which of course is completely
+  contradictory to the restriction to protected operations.  (To my
+  shame, I was misled into a different semantics by the "Not_Required"
+  as alternative in the poll, since I presumed that finally normal
+  subprograms renaming entries could get this aspect to communicate
+  their important synchronization property. Well, fooled me.)
+
+   "Synchronization_Kind =Optional" would be semi-ok.
+   "Synchronization =By_Any" sounds much better to me, now in context.
+
+end of Comment]
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, May 17, 2011  1:52 AM
+
+> AI05-0215-1/08  Pragma Implemented should be an aspect, renamed, and
+> better defined
+>    [The class of this AI was wrong; it modifies an Amendment AI, so it also has to be Amendment.
+>     Otherwise, it is unchanged.]
+>    Approve ______ Disapprove __ X ____ Abstain _______
+>
+> ============
+>
+> Why doesn't 9.5(18/3) simply say: "The Synchonization aspect is
+> inherited by derived types." ?
+
+Because this is an aspect of a subprogram, not of a type. Only types inherit
+aspects, subprograms never do. ("Subprogram" is never mentioned in 13.1(15/1)!).
+
+We could have defined inheritance of subprogram aspects, but since we didn't
+want most of them to be inherited, it would have made things messier. So the two
+aspects that do have a form of inheritance define it themselves.
+
+> The current verbage is rather confusing, since the neded other part of
+> it is in 16/3. Here is the draft of a(n
+> erroneous) comment that I was led to by 18/3:
+> ------
+> I am surprised that 9.5(18/3) seems to allow that
+> By_Protected_Procedure can become By_Entry in a redefining
+> declaration. Is this really intended, so that I call on a routine that
+> promises no barrier and then the redefining routine does block after
+> all? Not good!
+> -------
+> I know now that 16/3 prevents it, but why this completely convoluted
+> way of saying "is an inheritable aspect"?
+
+Because there are no "inheritable aspects" for subprograms.
+
+Also note that the two rules in question are separated because one is static
+semantics and one is a legality rule. Also note that your editor reversed these
+rules when he put this text into the Standard, because it otherwise had two
+static semantics sections separated by some legality rules. And it now puts the
+more important rule first.
+
+> I am unconfortable with the term "Optional" in this context after all,
+> since "Synchronization = Optional" definitely reads as if
+> synchronization were optional, which of course is completely
+> contradictory to the restriction to protected operations.
+
+I have absolutely no idea what you are talking about here. What "restriction to
+protected operations"?? There is none required by this aspect! It definitely
+allows completion by normal subprograms, just as any primitive operation of a
+synchronized interface does in Ada 2005. That's necessary for compatibility,
+at a minimum.
+
+I note Gary seemed to think this was significant as well, which indicates to me
+that either I (and a number of others) have missed something fundamental, or a
+number of people are very confused about synchronized interfaces.
+
+> (To my shame, I was misled into a different semantics by the
+> "Not_Required"
+> as alternative in the poll, since I presumed that finally normal
+> subprograms renaming entries could get this aspect to communicate
+> their important synchronization property. Well, fooled me.)
+
+I'm actually a bit surprised that we don't allow this aspect on all subprograms,
+but that's something to discuss in the future. In any case, a renaming does not
+have aspects of it's own; "By_Entry" is an unnamed property of a renamed much as
+"constant" is an unnamed property. It's arguable whether this was a good idea,
+but the mistake was made by Jean in the Paleozoic era of Ada, and its just a wee
+bit late to fix now.
+
+>  "Synchronization_Kind =Optional" would be semi-ok.
+>  "Synchronization =By_Any" sounds much better to me, now in context.
+
+A normal subprogram has no synchronization at all; By_Any implies (to me, at
+least) that the primitive routine does -- but that is clearly not required.
+
+> The title of the AI should be made matching the content.
+
+It is. "Pragma Implemented should be an aspect, renamed, and better defined"
+I had to shorten it a bit: "Pragma Implemented should be an aspect rather than a
+pragma, renamed to Synchronization, and better defined" would be better, but it
+is way too long for our tools. And keep in mind that this AI is changing an
+existing AI that defines "pragma Implemented", so not mentioning that at all
+seems wrong to me. Finally, the original reason for this AI was to fix bugs in
+pragma Implemented; the other things came later and not mentioning them at all
+seems wrong as well.
+
+"Pragma Implemented should be replaced by aspect Synchronization, and the
+definition improved" might be better, but it is still too long. And "replaced
+by" isn't quite what's happening here.
+
+Anyway, better suggestions welcome.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent