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.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!haven!uflorida!gatech!hubcap!billwolf
From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)
Newsgroups: comp.lang.ada
Subject: Re: Garbage Collection
Message-ID: <4067@hubcap.UUCP>
Date: 11 Jan 89 16:10:57 GMT
References: <4232@enea.se>
Sender: news@hubcap.UUCP
Reply-To: billwolf@hubcap.clemson.edu
List-Id: <comp.lang.ada>

>From article <4232@enea.se>, by sommar@enea.se (Erland Sommarskog):
> I'm glad to hear that Reference.all will survive the block exit.
> I am still a little puzzled, though. Assume that instead of a "simple 
> pointer" we actually have a linked list, declared as (limited) 
> private in some package. Then, it's Destroy routine will be called
> at block exit. Now, I don't know how you folks write your Assign
> procedures for linked lists, but I do simple pointer copying. 

    I copy the values, whatever they are.  If they are pointers,
    then pointers will be copied.  If they are ADTs, then ADTs
    will be copied.  If the user can't tolerate the costs of copying,
    the user is free to make his/her list a list of pointers rather
    than a list of objects.  

    Pointer copying constitutes structural sharing, which is unacceptable;
    if a user updates the copy, that must not propagate back to the original.

> Finally, Bill Wolfe has claimed that not having garbage collection
> helps the programmer to understands all aspects of his code, both
> time and space. Eh, there are some more aspects on the code than
> so. For example, that it really does what it supposed to. It may very
> elegantly sweep away all used memory and that, but tell us that
> 2 + 2 = 5. No good program. Fact is, in many applications, space is
> seldom an important problem, if at all. All you want to be sure of
> is that you really got rid all of you allocated, so that your interactive
> user donesn't get a dump after five hours work.

    Precisely why implicit destruction is a valuable aid to programmers,
    leaving them secure in the knowledge that whatever local variables
    they create will be automatically destroyed upon block exit, and free
    to concentrate on the other aspects of the application such as how
    much space the procedure will consume while it is active, which then
    feeds into the overall order-of-magnitude figure for space consumption.  



                                  Bill Wolfe

                           wtwolfe@hubcap.clemson.edu