Re: Garbage collection (was a spinoff of a spinoff of a GA diatribe)

[ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe)]

"W. Wesley Groleau (Wes)" <wwgrol@PSESERV3.FW.HAC.COM> writes:
>Stack objects are collected as a side effect of the call stack mechanism.

Ok.

>Implementations that transparently put "stack" variables on the heap
>usually automatically deallocate at end of scope.

Ok.

>Explicit use of the heap for non-composite objects is not often done--why
>would you?

Because you don't *know* it's non-composite.
Ada supports information hiding, remember?

>And with composites, the provider of the data type has the complete freedom
>of choice to extend a controlled type with GC, extend a controlled type
>without GC, or not use a controlled type.

Once again, the problem is information hiding, only this time it goes
the other way.  Now the problem is that the provider of the data type
has no idea what the client will want to do with it.  You cannot, for
example, decide to "not use a controlled type" without thereby demanding
that the client accept responsibility for manual mangement.  And if the
client is a generic package receiving this type as a parameter, the
client doesn't *know* whether it is required to do manual management
(last choice) or forbidden to (first choice).

>So, compared to the above, how big is the payoff of having GC imposed on
>you by the implementation?

Fighting words.  Nobody in this thread has been arguing that Ada ought
to *impose* GC on anyone, only that it would be better if it were not
the case in practice that native-code Ada compilers *deny* it to
everyone.

As far as I am concerned, better support for information hiding is not
the least of the benefits of automatic storage management.

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.