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

--- ai12s/ai12-0240-1.txt	2018/06/16 03:03:27	1.9
+++ ai12s/ai12-0240-1.txt	2018/10/19 05:59:55	1.10
@@ -1652,4 +1652,172 @@
 are talking about further additions to support secondary pointers such as
 those used for cursors. This doesn't mention that. -Tuck
 
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, October 10, 2018  3:05 PM
+
+[Replying to a message from Tucker Taft in another thread. - Editor.]
+
+>Intriguingly, the anonymous access types are emerging as useful for 
+>implementing the notion of temporarily borrowing an object in the 
+>context of "owning" access types.  See AI12-0240-1:
+>
+>http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0240-1.txt?rev=1.9
+
+This is not "intriguing" or "useful", but rather a downright evil (mis)usage 
+of anonymous access types. The primary purpose of using these [in AI12-0240-1] 
+is to provide a hack to avoid declaring explicitly what "kind" of owning 
+access type is involved. That is a terrible idea, because:
+  (A) owned access types are always pool-specific, while anonymous access 
+      types are always general. Moreover, the point of anonymous access types
+      is to allow easy inter-conversion, and that has to be banned for owned 
+      access types. Their use in this context is a complete and utter lie to 
+      any uninitiated reader.
+  (B) one wants to use the various kinds of owned access types in many 
+      contexts, and assuming the form of the declaration is unnecessarily
+      constraining to the programmer.
+  (C) note that there are at least four "kinds" of owned access types, so 
+      purely depending on the form of declaration is insufficient [to 
+      differentiate them].
+
+We (you and I) discussed privately better ways to declare these things, which 
+I wrote up in the alternative AI (AI12-0240-2), in large part because you 
+suddenly became unwilling to discuss needed changes to the proposal (as well
+as refusing to answer reasonable questions about the proposal, rather claiming
+"the SPARK folks have considered all of the issues" -- which I don't believe, 
+simply because I can't find any rules about owned access objects used in 
+constants in AI12-0240-1).
+
+In a private thread, we've been discussing ways to let the SPARK people have 
+better visibility into things that we're doing that might affect them -- but 
+this cuts both ways! The ARG ought to have better visibility into things that
+SPARK is doing that might interfere with future Ada features.
+
+>This AI probably won't make it into Ada 2020, but the SPARK folks are in
+>the process of adding a stripped-down version of it to SPARK, ...
+
+This is unfortunate, mainly because the proposal needs work (and 
+simplification!), and sticking it into SPARK in a half-baked form will make 
+a substantial constituency that will be against properly baking it.
+
+It's also unfortunate if a stripped down version of this AI doesn't make it 
+into Ada 2020, because it means that unbounded containers that can be used in
+parallel with checking on are either (a) impossible or (b) have to be written
+in non-Ada.
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, October 10, 2018  3:38 PM
+
+It sounds like somewhere along the way I dropped the ball on discussing 
+alternative approaches, and sorry for that.  We have been working away on 
+something based on AI12-0240-1 for inclusion in SPARK.  Be that as it may, I
+am still interested in alternatives.  I was sort of waiting for your 
+alternative (AI12-0240-2) to show up in my inbox, but I guess you uploaded it
+and expected me to go find it online (which is a reasonable expectation, but 
+alas, I never realized it was there).  I just went and looked at it, and it 
+is interesting but also quite different.  I'll share it with the SPARK team 
+and see what sort of comments they have on it.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, October 10, 2018  5:00 PM
+
+[Taking this private, as it's not interesting to everyone else.]
+
+> It sounds like somewhere along the way I dropped the ball on 
+> discussing alternative approaches, and sorry for that.  We have been 
+> working away on something based on AI12-0240-1 for inclusion in SPARK.  
+> Be that as it may, I am still interested in alternatives.  I was sort 
+> of waiting for your alternative (AI12-0240-2) to show up in my inbox, 
+> but I guess you uploaded it and expected me to go find it online 
+> (which is a reasonable expectation, but alas, I never realized it was 
+> there).
+
+It was on the agenda of the last meeting, so it wasn't exactly hidden. You 
+had pretty much stopped responding to my messages on the topic at that point,
+so I wasn't sure you remained interested.
+
+>I just went and looked at it, and it is interesting but also quite 
+>different.  I'll share it with the SPARK team and see what sort of 
+>comments they have on it.
+
+It's also not complete, in that I didn't make any attempt to define kinds 
+beyond "owned" and "unchecked". There needs to be at least a definition of a
+"viewer" kind, and possibly others.
+
+The idea of using subtypes was yours, I think. I didn't initially like it, 
+but I realized that in some cases, especially with "viewers", that there might
+be  a lot of these and having to tag every object would be a pain. Using types
+would force explicit conversions for these types all over the place, which 
+seems like overkill, especially for safe things like "viewers".
+
+OTOH, in normal use, there won't be many "owned" pointers, so it makes sense 
+to have those on the declaration (especially as they are so important).
+Thus, I eventually concluded that both forms are needed. (Note that I've 
+sometimes missed the ability to declare an aliased subtype so I didn't have 
+to remember to stick that on every object declaration; this feels the same 
+to me. That is one area where I think early Ada 9x was closer to correct -- 
+but we've agreed to disagree on that years ago and rehashing is not needed.)
+
+BTW, so far as I understand, it's not possible to build a doubly-linked list 
+solely with owned pointers; one of them has to be some other kind (and the 
+only proposed one that works is "unchecked". That suggests that for 
+ADT/container use in particular one has to have more than just owned 
+pointers.
+
+The requirement to effectively declare the ownership mappings might not be 
+necessary, in that one probably could derive it from the various uses of the
+owned pointers (at least in ADT cases, where those are all in the private part
+and body). However, that would mean that Ada's one-pass like 
+reading/compilation model would have to be abandoned -- that might be a mess 
+in some compilers. (Ahem, Janus/Ada in particular.) Perhaps there is a better
+way to do it that doesn't require quite so much detail.
+
+Note of course that I was trying to solve a different problem than
+AI12-0240-1: specifically, ownership in ADTs so that the implementation can 
+use pointers without having to resort to Global All or something equally 
+annoying (which of course would prevent parallel use when checking is 
+enabled).
+
+It would be best if we could solve both of these problems with one solution,
+even if we only standardize the minimum corner for now (as roughly described
+in AI12-0240-2).
+
+Anyway, comments welcome, if only because I don't have many complete examples
+to consider, so I really don't know how this works in practice (I've mainly
+considered the doubly linked list container when designing AI12-0240-2.)
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, October 10, 2018  5:08 PM
+
+> [Taking this private, as it's not interesting to everyone else.]
+
+Apparently I did a bad job of that. :-) I intended that message just for 
+Tucker, since it mostly discussed our previous private conversations on this 
+topic.
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, October 10, 2018  5:11 PM
+
+Thanks for the background, and sorry for the misunderstanding.  It is 
+probably safe to assume that when I stop responding, it is because my 
+brain just overflowed, and I have forgotten to reply and now the e-mail is
+buried in a sea of other e-mails.  I have also been traveling an insane 
+amount this year, having traveled across the "pond" eight times since 
+January, including two 2-week trips to Japan.  So my brain is "mush" much 
+of the time due to jet lag.
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Thursday, October 11, 2018  7:00 PM
+
 ***************************************************************