🚀 go-pugleaf

From wright@hsi.UUCP (Gary Wright):
> Another area that concerns me that hasn't been discussed is the interaction
> between exceptions and memory management.  My understanding is that
> when an exception is raised, execution may resume after any number of
> "scopes" have been exited.  Will the objects in those scopes be
> guaranteed to be destroyed?  

   This is the only reasonable way to handle the situation.  Destruction
   would occur as part of the scope exit, and in fact this is exactly
   what happens now in Ada 83 (sort of -- the objects are no longer
   accessible, and may as well be dead; if there is a GC system running,
   it's perfectly free to take over at this point).  

   An interesting question is, "What happens if the destruction process
   raises another exception?"; in this case, the most likely answer is
   that the two exceptions should be treated as if they arose concurrently;
   incidentally, an extremely interesting article on that topic appears in 
   the current issue of ACM SIGADA Ada Letters ("Programming Atomic Actions 
   in Ada", page 67).  This is one place where the Ada 9X effort is really
   pushing forward the state of the art as far as programming languages are
   concerned. 
     
> The point is that there *are* tradeoffs.  Not using GC "might introduce"
> reuse problems also.  What is the cost associated with "avoiding" GC?

   Could you please elaborate on how a self-managing component could 
   possibly cause reuse problems?   

   As far as other costs go, the copying burden comes for free because
   we need to assure update-independent semantics anyway.  The real cost
   is simply the space which might be taken up by the destruct code, and
   here we have a time-space tradeoff.  Either we store the destruct code
   and get faster space management, or we forget about destruct code and
   live with slower allocation service.  

   Perhaps this really indicates that both ideas are necessary.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu