Path: utzoo!utgpu!watmath!clyde!att!ucbvax!hplabs!sri-unix!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.lang.ada
Subject: Re: Collective response to := messages
Message-ID: <812@quintus.UUCP>
Date: 6 Dec 88 01:54:22 GMT
References: <808@quintus.UUCP> <3740@hubcap.UUCP>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 36

In article <3740@hubcap.UUCP> billwolf@hubcap.clemson.edu writes:
>From article <808@quintus.UUCP>, by ok@quintus.uucp (Richard A. O'Keefe):
>> It would be a service if you could elaborate on this [...]

>    The programmer is Johnny-on-the-spot.  He/she KNOWS whether or not
>    a given object is no longer needed.  All that is necessary is an 
>    indication of this fact via the command DESTROY (Unneeded_Object).

This simply isn't true.  If I write a library routine which is passed
some linked data structure, I may be able to tell whether my traversal
of it has finished, but that leaves me with no idea whatsoever of
whether I was given the last reference to it (in which case now is the
time to delete it) or not.  Or suppose some "object" has references to
some other objects, and I DESTROY(..) the first object.  Should it
DESTROY(..) the other objects?  In that case it may destroy things which
other objects still refer to!  But if it doesn't, and it held the only
references to those objects, their space will not be reclaimed.  Is
Johnny on the spot?  NO!  The programmer who coded the implementation
of that object has _no_idea_ how other programmers will use it.  There
has been quite a lot of discussion about this in comp.lang.c++ .

     Let me apply billwolf@hubcap's general principle to another case:

	The programmer is Johnny-on-the-spot.  He/she KNOWS whether a
	given object is an integer or a float.  All that is necessary
	is an indication of this fact via the use of + for integers
	and #+ for floats.  We don't need any of this strong typing
	nonsense!

Automatic storage management, like automatic operator selection, means
that the programmer misses an opportunity to make a mistake.  There 
_are_ garbage collection methods around where the overhead of
garbage collection is a constant times the cost of allocation.

ADA was explicitly designed not to require garbage collection.
Since it was meant to be useful for real-time work, that was appropriate.