Re: Garbage Collection in Ada

[rogoff@sccm.Stanford.EDU (Brian Rogoff)]

"Norman H. Cohen" <ncohen@watson.ibm.com> writes:
   Robert A Duff wrote:

   > In article <mheaney-ya023280000311962335300001@news.ni.net>,
   > Matthew Heaney <mheaney@ni.net> wrote:
   > >Language designers: any reason why overloading "all" would be too hard?
   > 
   > Well, functions return values (or constant objects, if you want to be
   > precise in Ada 95 terms), whereas "P.all" returns a variable (if P is an
   > access-to-variable type).  So it wouldn't work.  

   The same scheme that Ada 95 uses to allow programmers to redefine the
   behavior of "new" could have been used to allow redefinition of the
   behavior of ".all".  The type System.Storage_Pools.Root_Storage_Pool
   could have been given another primitive operation to be overridden by
   those defining their own storage-pool types:

      procedure Dereference
	 (Pool                     : in out Root_Storage_Pool;
	  Storage_Address          : in out Address;
	  Storage_Size_In_Elements : in Storage_Elements.Storage_Count;
	  Alignment                : in Storage_Elements.Storage_Count);

This looks almost exactly like a proposal I read (a long time ago, on a web 
page long since forgotten) for adding persistence to Ada 95. The main 
difference is that Storage_Address was of type "Access_Type", which was a 
generic formal parameter to the Storage_Pools package, and another parameter 
to Dereference was a System.Address type. There was also a Rereference 
procedure for converting System.Address types back to Access_Types.

   <... snipping description of some the things this might allow ...>

This seems, at first naive glance, to provide all of the hooks to do GC and 
more, in a very Ada-like way. The idea seems to have been around for a 
while too, perhaps hundreds of web-years (at least 10 months). So what are 
the drawbacks? 

-- Brian