CVS difference for ai12s/ai12-0330-1.txt

Differences between 1.9 and version 1.10
Log of other versions for file ai12s/ai12-0330-1.txt

--- ai12s/ai12-0330-1.txt	2020/12/11 22:22:25	1.9
+++ ai12s/ai12-0330-1.txt	2020/12/17 05:22:14	1.10
@@ -1,4 +1,4 @@
-!standard N(0)                                      20-12-09  AI12-0330-1/05
+!standard N(0)                                      20-12-15  AI12-0330-1/06
 !class Amendment 19-04-05
 !status Amendment 1-2012 19-05-09
 !status ARG Approved 14-0-1  20-12-09
@@ -41,12 +41,11 @@
 Accessibility level
 An accessibility level is a representation of the lifetime of an entity in
 terms of the level of dynamic nesting within which the entity is known to exist.
-Given an access value that designates some object, the dynamic accessibility
-checks prevent a dangling reference by ensuring that the accessibility level 
-of the designated object is no deeper than that of the type of the access value.
-Based on static nesting, there are corresponding legality rules that require
-that the accessibility level of the designated object not be statically deeper
-than that of the access type.
+Dynamic accessibility checks ensure that a referce does not outlive the entity
+to which it refers, by checking that the level of the reference is no deeper 
+than the level of the reference. Based on static nesting, there are 
+corresponding legality rules that the level of the entity is not statically
+deeper than that of the reference.
 
 Aggregate
 An aggregate is a construct used to define a value of a composite type by 
@@ -980,5 +979,479 @@
 I found one needed change given another wording change that's in the hopper.
 More on that once Steve gets back from vacation and can review it to ensure 
 that it fixes his concern.
+
+***************************************************************
+
+From: Bob Duff
+Sent: Wednesday, December 9, 2020  11:01 AM
+
+Suggested change to the wording for Suppress in AI12-0330-1.
+
+    To suppress a check is to promise that it cannot fail,
+    and to request that the compile optimize by disabling
+    the check. The compiler is not required to honor this
+    request.
+
+***************************************************************
+
+From: Arnaud Charlet
+Sent: Wednesday, December 9, 2020  11:06 AM
+
+>     To suppress a check is to promise that it cannot fail,
+>     and to request that the compile optimize by disabling
+
+                              compiler
+
+>     the check. The compiler is not required to honor this
+>     request.
+
+Note that one common case causing wrong expectations with customers is when 
+the compiler can statically determine that a runtime check will fail.
+In this case, a systematic raise is inserted instead of a runtime check and 
+this systematic raise is *not* suppressed by GNAT, even when specifying pragma
+Suppress.
+
+***************************************************************
+
+From: Edmond Schonberg
+Sent: Wednesday, December 9, 2020  11:14 AM
+
+>>    To suppress a check is to promise that it cannot fail,
+
+I would say “assert” rather than “promise”.
+
+***************************************************************
+
+From: Richard Wai
+Sent: Wednesday, December 9, 2020  11:14 AM
+
+I don't really see the purpose of calling it a "request". I really is a
+permission given by the user to the compiler, and the user aught to see it
+that way. I feel like "request" is too strong, it suggests some responsibility
+for the compiler to "try", but in fact the RM does not make any such 
+requirement on the compiler. I think "request" is therefore misleading. And it 
+seems the last sentence is there exactly to make that clear. The Suppress
+pragma is really an optimization hint, and in all other languages, those are
+weak suggestions and everyone recognizes that, and I think we should give a
+similar impression to the user.
+
+Using the word "permission" suggest that it is the compiler's decision (which
+it is). 
+
+I'd think "To suppress a check is to promise that it cannot fail, and to give 
+permission to the compiler to omit check." is more concise, and is closer to 
+what it actually means to "Suppress" a check.
+
+***************************************************************
+
+From: Bob Duff
+Sent: Wednesday, December 9, 2020   1:09 PM
+
+> I don't really see the purpose of calling it a "request". I really is 
+> a permission given by the user to the compiler, and the user aught to 
+> see it that way. I feel like "request" is too strong, it suggests some 
+> responsibility for the compiler to "try", but in fact the RM does not 
+> make any such requirement on the compiler.
+
+I don't agree. It's not a matter of "try" -- the compiler is using a 
+deterministic algorithm.
+
+The compiler should honor the request unless there's a good reason not to, so 
+"request" is neither too weak nor too strong. The whole point of suppression 
+is efficiency.
+As 11.5 says:
+
+                            Implementation Advice
+
+28  The implementation should minimize the code executed for checks that have 
+    been suppressed.
+...
+28.a        Implementation Note: However, if a given check comes for free (for
+            example, the hardware automatically performs the check in parallel
+            with doing useful work) or nearly free (for example, the check is
+            a tiny portion of an expensive run-time system call), the
+            implementation should not bother to suppress the check. Similarly,
+            if the implementation detects the failure at compile time and
+            provides a warning message, there is no need to actually suppress
+            the check.
+
+The last sentence above is the case Arno mentioned, except a warning is not 
+always appropriate.
+
+As I said during the meeting, if the compiler is generating extra instructions
+to perform a check, and it fails to remove those instructions when the check
+is suppressed, and that causes significant inefficiency, then that's a
+compiler bug.  (And note that unlike Robert Dewar, I do not consider "compiler
+bug" to be synonymous with "nonconformance".)  As a user I would report such a
+bug, and as a compiler writer I would fix it.
+
+The word "permission" is too weak -- it implies that a compiler that ignores
+Suppress is just as good as one that implements it properly.
+
+But none of this is important -- it's just the glossary -- so I'll shut up 
+now.  ;-)
+
+***************************************************************
+
+From: Bob Duff
+Sent: Wednesday, December 9, 2020  1:15 PM
+
+> I would say “assert” rather than “promise”.
+
+Yes, that's better.
+
+Should we also say something like "It is wrong to suppress checks that can
+fail" or "Suppressing checks that can fail can cause programs to malfunction
+in arbitrary ways"?
+Lots of people don't understand that (e.g. they expect to get wraparound
+semantics when suppressing overflow checks).
+
+***************************************************************
+
+From: Edmond Schonberg
+Sent: Wednesday, December 9, 2020   1:28 PM
+
+> Should we also say something like "It is wrong to suppress checks that 
+> can fail" or "Suppressing checks that can fail can cause programs to 
+> malfunction in arbitrary ways”?
+
+Yes to the second formulation (in other words, if you suppress a check that 
+would fail, all bets are off).  I’d rather avoid “promise” and “wrong” because
+they have a moral ring that doesn’t belong. I don’t know if saying “the 
+behavior of the program is undefined” would be helpful.
+
+***************************************************************
+
+From: Bob Duff
+Sent: Wednesday, December 9, 2020  2:07 PM
+
+Taking into account some suggestions:
+
+    To suppress a check is to assert that it cannot fail, and to request
+    that the compile optimize by disabling the check. The compiler is
+    not required to honor this request. Suppressing checks that can fail
+    can cause programs to behave in arbitrary ways.
+
+> I don’t know if saying “the behavior of the program is undefined”
+> would be helpful.
+
+Well, given the number of people who misunderstand what "undefined behavior"
+means in the C standard, I'd rather not. I changed "malfunction" to "behave"
+above, because the worst thing is when it works just fine -- until you make 
+an unrelated change a year later. I've seen people say, "I think this C code 
+has undefined behavior. So why didn't I get a SIGSEGV?"
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, December 9, 2020  2:34 PM
+
+> Taking into account some suggestions:
+> 
+>    To suppress a check is to assert that it cannot fail, and to request
+>    that the compile optimize by disabling the check. The compiler is
+         "compiler" 
+>    not required to honor this request. Suppressing checks that can fail
+>    can cause programs to behave in arbitrary ways.
+
+Looks good.
+
+***************************************************************
+
+From: Steve Baird
+Sent: Wednesday, December 9, 2020  5:03 PM
+
+Agreed.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, December 10, 2020  2:51 PM
+
+>Taking into account some suggestions:
+>
+>    To suppress a check is to assert that it cannot fail, and to request
+>    that the compile optimize by disabling the check. The compiler is
+>    not required to honor this request. Suppressing checks that can fail
+>    can cause programs to behave in arbitrary ways.
+
+One minor comment. I had a brief moment of confusion when encountering "it" 
+in the above (what cannot fail?), and writing out "the check" only adds 6 
+characters (and we're not paying by the character!) and eliminates any such
+confusion. Moreover, we repeat "the check" later, so it's not like we're 
+avoiding redundancy. So I used:
+
+   To suppress a check is to assert that the check cannot fail, and to request
+    that the compiler optimize by disabling the check. The compiler is
+    not required to honor this request. Suppressing checks that can fail
+    can cause programs to behave in arbitrary ways.
+
+I rekeyed this since I'm working at home, and never noticed the other typo -- 
+of course, I didn't copy it, either, since I read what it was supposed to say 
+and not what it actually says.
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Thursday, December 10, 2020  10:42 AM
+
+Here is a first draft [of the glossary entry for Accessibility level - 
+Editor].  Comments welcome.
+
+Accessibility Level : An accessibility level is a representation of the 
+lifetime of an entity in terms of the level of dynamic nesting within which
+the entity is known to exist.  Formally it is defined in terms of the set of
+masters in which it is nested.  Given a value of a given access type that 
+designates some object, the dynamic accessibility checks ensure that the 
+accessibility level of the designated object is no deeper than that of the 
+access type, to prevent a reference to an object that has gone out of scope.
+Based on the static nesting of the master constructs associated with the 
+relevant masters, there are corresponding legality rules that require that the
+accessibility level of the designated object not be statically deeper than
+that of the access type.
+
+***************************************************************
+
+From: Gary Dismukes
+Sent: Thursday, December 10, 2020  12:57 PM
+
+> Here is a first draft.  Comments welcome.
+
+It reads well, though is a bit lengthy for a glossary entry.  This would now
+be the longest entry, after the one for primitive operations (which is also
+rather lengthy), but maybe that's OK.  It does seems like the second sentence
+could be left out ("Formally it is defined..."), especially since these are
+supposed to be "informal" definitions. ;-)
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Thursday, December 10, 2020  1:47 PM
+
+Here is an attempt to "dumb it down" a bit ... ;-)
+
+-------
+
+Accessibility Level : An accessibility level is a representation of the 
+lifetime of an entity in terms of the level of dynamic nesting within which
+the entity is known to exist. Given an access value that designates some
+object, the dynamic accessibility checks ensure that the accessibility level
+of the designated object is no deeper than that of the type of the access
+value, to prevent a dangling reference.  Based on static nesting, there are
+corresponding legality rules that require that the accessibility level of the
+designated object not be statically deeper than that of the access type.
+
+---
+
+Any better?
+
+***************************************************************
+
+From: Gary Dismukes
+Sent: Thursday, December 10, 2020  1:57 PM
+
+Yes, that looks pretty good.  One minor change I suggest is removing the word 
+"the" from "the dynamic accessibility checks".
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Thursday, December 10, 2020  2:32 PM
+
+Works for me!
+
+***************************************************************
+
+From: Ed Schonberg
+Sent: Thursday, December 10, 2020  3:20 PM
+
+Looks good, but I would move “ prevent a dangling reference” earlier in the
+second sentence so that the purpose of the construct is more immediately
+stated.
+
+   The dynamic accessibility checks prevent a dangling reference by ensuring
+   that the accessibility level ….
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, December 10, 2020  3:35 PM
+
+Yea verily!
+
+I was going to complain that your original version had messed up the 
+relationship between master and master construct. Since that area is plenty 
+confusing to experts, I don't want anything "official" that is incorrect, even
+if not normative. (Especially as we have carefully crafted Glossary entries
+for the terms, don't want to contradict or even repeat those.)
+
+But I see you got rid of all of that, so I didn't have to write the above. ;-)
+
+***************************************************************
+
+From: Erhard Ploedereder
+Sent: Thursday, December 10, 2020  8:25 PM
+
+> Here is a first draft.  Comments welcome.
+> -Tuck
+ 
+>Accessibility Level : An accessibility level is a representation of the 
+>lifetime of an entity in terms of the level of dynamic nesting within which
+>the entity is known to exist.  Formally it is defined in terms of the set of
+>masters in which it is nested.
+
+who or what is the nested "it"? acc.level, lifetime, entity. Be more specific.
+
+>Given a value of a given access type that designates some object, the dynamic
+>accessibility checks ensure that the accessibility level of the designated
+>object is no deeper than that of the access type, to prevent a reference to
+>an object that has gone out of scope.
+
+"has gone out of scope" -> "no longer exists" or "whose lifetime has ended". 
+An object can be out of scope, and yet exist and be referenceable. Think e.g.
+about propagated local exceptions or about private data.
+
+>Based on the static nesting of the master constructs associated with the 
+>relevant masters, there are corresponding legality rules that require that
+>the accessibility level of the designated object not be statically deeper 
+>than that of the access type.
+
+***************************************************************
+
+From: Erhard Ploedereder
+Sent: Thursday, December 10, 2020  8:30 PM
+
+>Accessibility Level : An accessibility level is a representation of the 
+>lifetime of an entity in terms of the level of dynamic nesting within which
+>the entity is known to exist. Given an access value that designates some
+>object, the dynamic accessibility checks ensure that the accessibility level
+>of the designated object is no deeper than that of the type of the access
+>value, to prevent a dangling reference.  Based on static nesting, there are
+>corresponding legality rules that require that the accessibility level of the
+>designated object not be statically deeper than that of the access type.
+
+Looks good/better to me too.
+
+***************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Friday, December 11, 2020  1:52 AM
+
+> The first sentence:
+> 
+>   An accessibility level is a representation of the lifetime of an entity in
+>   terms of the level of dynamic nesting within which the entity is known to
+>   exist.
+> 
+> is the most important.  I would welcome rephrasings of this which you would
+> find more enlightening.
+
+Maybe simply:
+Accessibility Level : An accessibility level is the level of dynamic nesting 
+within which the entity is known to exist.
+
+I find "representation of the lifetime" confusing. How do you represent a 
+lifetime?
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Friday, December 11, 2020  3:19 AM
+
+>I find "representation of the lifetime" confusing. How do you represent
+>a lifetime?
+
+Depends on the context. I would have answered "62" without any. :-) I don't 
+see any problem with representing a lifetime so long as the context is clear.
+One does it all the time, the representation of my lifetime is 62 years, since
+it implies a duration ("time", you know). In this case, it's talking about how
+long an object exists, that is, the duration of it's "life", or "lifetime" for
+short. I would have preferred this concept was called "lifetime" in the first
+place, and I think it is quite important to get that into the discourse (I
+always have to think about lifetimes to understand accessibility, even now
+after 25+ years).
+
+If I had a quibble with this wording, is that it is rather focused on the 
+motivating case (dangling objects), while there are many other uses within Ada
+and a few that are ultimately more important (particularly, the dangling
+tagged type checks of class-wide returns). So making the wording a bit more
+abstract and then giving access types as an example would probably be better.
+(By this, I mean that I'd try to define "deeper" and "statically deeper"
+checks without giving a specific use, and then give an example. I'm not going
+to try a rewording minutes before bed, though.)
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Friday, December 11, 2020  6:13 PM
+
+Now that it's daytime :-), here's the sort of thing I was thinking about:
+
+Accessibility Level : An accessibility level is a representation of the
+lifetime of an entity in terms of the level of dynamic nesting within which
+the entity is known to exist. Dynamic accessibility checks ensure that an
+entity does not outlive the lifetime of some related entity, by checking that
+the level of the first entity is no deeper than the second entity. Based on
+static nesting, there are corresponding legality rules that the level of the
+first entity is not statically deeper than the second entity. For instance,
+given an access value that designated some object, accessibility checks
+prevent a dangling reference by ensuring that the object outlives the access
+type.
+
+The problem (not very strong, admittedly) I had with the previous wording is
+that it talks like the only reason for these checks is access types, and that
+is far from the reality. The fact that the checks pair for all uses, and that
+there are many uses, seems lost in Tucker's proposed glossary entry.
+
+If I had been defining this in the first place, I would have called these
+"lifetime checks" and "outlive" would have been a technical term. For most
+people, "accessibility" is just as meaningful as "muggywump" or Steve's
+"frobisher" (noise words used as the placeholder for a term when discussing
+possible rules). I always have to translate things into lifetime in order to
+even understand them at all; the above is the way I think of these rules.
+
+[Tucker has told me a zillion times why they didn't do that, I realize they
+had reasons, they just aren't very compelling. :-)]
+
+I can imagine why the above might be too much for some, as it rather diverges
+from the orthodoxy. Perhaps there is an intersection that would be better than
+either.
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, December 15, 2020  4:34 PM
+
+Yours seems to be getting pretty abstract.  I also think the sense of the
+check is now backwards, as a result of your switching to "outlive".  Let me
+see if I can hit that intermediate point you mention, and make sure it says
+the correct thing:
+
+Accessibility Level : An accessibility level is a representation of the
+lifetime of an entity in terms of the level of dynamic nesting within which
+the entity is known to exist. Dynamic accessibility checks ensure that a
+reference does not outlive the entity to which it refers, by checking that the
+level of the entity is no deeper than the level of the reference.
+Based on static nesting, there are corresponding legality rules that the level
+of the entity is not statically deeper than that of the reference.
+
+------
+
+I have used the rather generic term "reference" which I think handles pretty 
+much any sort of "relation" we worry about.
+
+***************************************************************
+
+From: Tullio Vardanega
+Sent: Wednesday, December 15, 2020  8:37 AM
+
+I believe this works.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, December 15, 2020  9:56 PM
+
+This is roughly what I had in mind, only better. Thanks.
 
 ***************************************************************

Questions? Ask the ACAA Technical Agent