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

Differences between 1.14 and version 1.15
Log of other versions for file ai05s/ai05-0111-1.txt

--- ai05s/ai05-0111-1.txt	2010/05/20 02:45:15	1.14
+++ ai05s/ai05-0111-1.txt	2010/06/14 01:24:49	1.15
@@ -5377,219 +5377,3 @@
 
 ****************************************************************
 
-From: Bob Duff
-Sent: Monday, May 17, 2010  2:55 PM
-
-Here's my last bit of homework, in preparation for the phone meeting this
-Thurday, May 20, at 3:00 PM EST.
-
-This is from the Minutes of Meeting #40:
-
-> Action item to everyone to look at this and see how (or if) they might
-> use it.
-
-OK, I've studied this stuff some more.
-
-If it existed, I would certainly use it sometimes.
-I'd use it whenever large numbers of objects can be grouped into those with
-similar lifetimes.  E.g. a giant hash table, where all the nodes go away when
-the hash table does.
-
-In fact, I've built the same sort of stuff myself, except without language
-support, it necessarily had some drawbacks:
-
-(1) Unsafe (possible dangling pointers), because there was no
-    check that when you copy an access value, the right subpool
-    is "reachable".
-
-(2) Unreadable, because there was no syntax for specifying the
-    subpool on the "new".  Instead, I had a global "current subpool"
-    variable, which had to be set up beforehand.  (Actually, a
-    stack of them, with limited-controlled types managing the
-    setup and teardown -- quite complicated.)
-
-(3) Task-unsafe, because of that global variable.
-
-(4) No support for allocating controlled objects or tasks
-    within a subpool (if you try, the runtime system gets
-    deeply confused).
-
-(5) It was technically wrong (relied on implementation-specific
-    behavior not guaranteed by the language).
-
-I would be pretty happy with a solution that solved just (2) and (3), which
-seems pretty easy (see the title of this AI!).  In the past, this suggestion has
-been shot down, saying "we can't have a new way of creating erroneous behavior"
-(i.e. (1) above).  I have never understood that argument.  If a new feature is
-unsafe, you have to look at what it replaces.  Unsafe subpools would replace
-some uses of Unchecked_Dealloc.  Unsafe subpools are unsafe, but they're still
-safer than Unchecked_Dealloc -- by far, in my experience.  So unsafe subpools
-would make Ada programs safer, on the whole.
-
-Support for unsafe subpools exists in C and C++, which is our competition if
-you're looking at the embedded world.  If a C++ programmer says "Ada can't do
-X", we can usually answer, "Oh, yes it can, you just have to do it in a more
-disciplined, safer way."  That's fine. But in this case, our current answer is,
-"Right, you can't do that in Ada, and we're not going to let you, because it's
-unsafe." That's not an acceptable answer to someone who needs to do X.
-
-Given the widespread use of unsafe subpools (AKA user-defined malloc, placement
-new, etc) in C and C++, I find the question posed in the minutes "see... if...
-they might use it" to be rather puzzling.
-
-Safe subpools, as proposed by this AI, prevent (1), which is very cool.
-On the other hand, there's a fair amount of implementation complexity for that.
-
-I can't get too excited about (4).  From a practical point of view, I'd be happy
-if allocating such "fancy" things raised an exception.  That's ugly of course --
-but that's a more theoretical point of view.  There's a huge implementation
-complexity in solving (4).
-
-I believe that a modern, efficient implementation of garbage collection would do
-far more to promote the use of Ada than this AI.  The !example, of a
-"long-running web server" seems appropriate for GC -- no hard real-time
-constraints, not safety critical, etc.  On the other hand, the implementation
-cost of this AI is far less than that of a really good GC.
-
-Summary: I have mixed feelings.  :-(
-
-****************************************************************
-
-From: Bob Duff
-Sent: Monday, May 17, 2010  3:11 PM
-
-> Action item to everyone to look at this and see how (or if) they might
-> use it.
-
-Anecdote: Last weekend, I was helping my son Bill who is writing an Ada program
-to do some text processing, involving reading (arbitrarily long) lines of text
-from input files, and grinding upon them in various ways.  This required fairly
-complicated data structures containing Strings and other stuff.
-
-Subpools (safe or unsafe) containing Strings would have come in very handy.
-We ended up using Unbounded_Strings, which works, but it's awfully heavy
-syntactically.  You end up either converting back and forth between String and
-Unbounded_String all over, or using calls to Element, Replace_Element, and the
-like instead of normal array indexing and the like.  A loop such as:
-
-    loop
-        create subpool;
-        process one file, doing "new String..." a lot;
-        destroy subpool;
-    end loop;
-
-would have made the code rather more readable, I think.
-And it's not too hard to make sure the subpool is destroyed at the right time to
-avoid dangling pointers.
-
-GC would have been another good solution.
-
-I suspect any of the three (safe subpools, unsafe subpools, or GC) would have
-been more efficient than all that string copying we ended up doing.   (E.g. what
-do you do when you want to rename a slice of an Unbounded_String?!)
-
-****************************************************************
-
-From: Bob Duff
-Sent: Monday, May 17, 2010  3:18 PM
-
-> Anecdote: Last weekend, I was helping my son Bill who is writing
-
-For a good time, google "the plural of anecdote is data".  ;-)
-
-Anybody else going to do this homework?...
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Monday, May 17, 2010  8:37 PM
-
-> We ended up using Unbounded_Strings, which works, but it's awfully
-> heavy syntactically.  You end up either converting back and forth
-> between String and Unbounded_String all over, or using calls to
-> Element, Replace_Element, and the like instead of normal array
-> indexing and the like.  A loop such as:
-
-That's a problem with unbounded strings that doesn't seem to have much to do
-with subpools. Unbounded_Strings shouldn't be so clunky, period. Unfortunately,
-fixing that would take a fairly massive redesign, and would be incompatible in
-some corner cases.
-
-Tucker's indexing syntax might help with this as well. (We ought to consider
-defining it for bounded and unbounded strings.)
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Monday, May 17, 2010  8:48 PM
-
-> Given the widespread use of unsafe subpools (AKA user-defined malloc,
-> placement new, etc) in C and C++, I find the question posed in the
-> minutes "see... if... they might use it" to be rather puzzling.
-
-I totally agree with this logic. I don't actually see the point of "safe
-subpools"; they're a lot of work to fix something that isn't (seriously) broken.
-
-> Safe subpools, as proposed by this AI, prevent (1), which is very
-> cool.
-> On the other hand, there's a fair amount of implementation complexity
-> for that.
->
-> I can't get too excited about (4).  From a practical point of view,
-> I'd be happy if allocating such "fancy" things raised an exception.
-> That's ugly of course -- but that's a more theoretical point of view.
-> There's a huge implementation complexity in solving (4).
-
-Here I disagree with you, on both points. If we had simple unsafe subpools, it
-makes perfect sense for the allocated objects to be associated with the subpool,
-and thus go away when the subpool does. That's simple to implement in that it
-works the same way as it does for declared access types, just associated with a
-different object. The only problem that might come up is if the implementation
-cannot handle a dynamically determined object for the "master" of an allocated
-object. That shouldn't be the case for a chain-based implementation (only the
-root of the chain needs to be identified, and that can be treated as a normal
-object [an address]). An implementation that does things statically might have
-more trouble, but I can't figure out how a static implementation would even work
-for allocated objects - it seems like there would have to be a list somewhere.
-
-> I believe that a modern, efficient implementation of garbage
-> collection would do far more to promote the use of Ada than this AI.
-> The !example, of a "long-running web server" seems appropriate for GC
-> -- no hard real-time constraints, not safety critical, etc.  On the
-> other hand, the implementation cost of this AI is far less than that
-> of a really good GC.
->
-> Summary: I have mixed feelings.  :-(
-
-Mine aren't mixed. Tucker's current proposal is too much. Solving (2), (3), and
-(4) is relatively easy and might be worthwhile, but I see no reason to go beyond
-that. And I'd rather do nothing than make a large implementation burden for a
-relatively rare use. (Remember that we've made it quite a bit easier to create a
-container that can handle all of this stuff at a higher level; that doesn't
-solve every problem but it solves a whole lot of them.)
-
-I had seriously considered writing an alternative AI that did just (2), (3), and
-(4), but I decided to go on vacation instead. Now I don't have time... ;-)
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Tuesday, May 18, 2010  9:07 PM
-
-One thing worth noting in the update
-to AI05-0111, is that there are no
-compile-time checks required to support
-the "reachability" requirements.
-My guess is that this simplifies
-the implementation significantly,
-since it can be offloaded almost
-entirely to the run-time system,
-which is almost always easier
-to update and debug than the compiler.
-
-Also, the reachability checks are
-now described in just a handful of
-paragraphs, in 13.11.6, and are
-hopefully easier to understand than before.
-
-****************************************************************

Questions? Ask the ACAA Technical Agent