From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uflorida!gatech!hubcap!wtwolfe
From: wtwolfe@hubcap.UUCP (Bill Wolfe)
Newsgroups: comp.lang.ada
Subject: Re: Garbage Collection
Message-ID: <3950@hubcap.UUCP>
Date: 20 Dec 88 19:04:59 GMT
References: <4176@enea.se>
Organization: Clemson University, Clemson, SC
List-Id: <comp.lang.ada>

>From article <4176@enea.se>, by sommar@enea.se (Erland Sommarskog):
> Sworn enemy to garbage collection Bill Wolfe writes:
>>     The deallocation of every object in the local environment is
>>     performed as an automatic service when a procedure, function,
>>     or local block is exited.  This is not garbage collection,
>>     because the programmer has implicitly directed that the 
>>     destruction be performed.  
> 
> I read this as "on block exit all memory allocated to variables
> declared in that block should be deallocated". 
>   Isn't this very dangerous? What if programmer copied the object to
> a variable declared in a outer block? Or stored it in a table of some
> sort in a subprogram call made in block? 

   Not at all.  If a programmer assigns the value stored in some local
   object to some nonlocal object, then we simply have a new value for
   a nonlocal object, assuming we have not engaged in the foul practice
   of structural sharing.  Those who engage in structural sharing will
   get the run-time errors they deserve for engaging in such space-hacking. 

   Now there is, of course, the problem that the practice of assigning to
   nonlocal objects is somewhat distasteful, since this amounts to a
   "side effect" of a procedure or function.  The rap on side effects
   is that they frequently are not properly documented, and thus make
   a major contribution to the difficulty of understanding a program.

   In addition, optimizing compilers find it difficult to completely 
   define the relationship between procedures or functions and their
   enclosing environment, thus making the relevant optimizations costly.

   So... language designers to the rescue!!!  The solution to this
   problem has been discussed in recent issues of Sigplan Notices,
   and it is this:  Provide a scheme whereby procedures and functions
   have, by default, no relationship to their surrounding environment
   other than that which is explicitly documented in the parameter
   structure.  Then provide a facility whereby one can explicitly
   "poke holes in the shield" for selected external objects.  

   The maintainers are happy, because for once they can read the
   specification of a procedure or function and be certain that
   it does nothing which is not documented in that specification.

   The writers of optimizing compilers are absolutely ecstatic.  

   And the programmers can do their debugging faster as well.  

   But sadly for the programmers who pride themselves on obscure code, 
   there is now one less form of sloppiness available for their use.

   Oh, well, perhaps they'll find some comfort in C...


                                  
                                       Bill Wolfe

                               wtwolfe@hubcap.clemson.edu