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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,a29f6c543c430f19
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: GC - again, :-)
Date: 1997/05/04
Message-ID: <dewar.862752069@merv>#1/1
X-Deja-AN: 239280828
References: <JSA.97Apr29155844@alexandria>
 <Pine.SGI.3.95.970430110433.18224A-100000@shellx.best.com>
 <01bc5742$bf3c7640$d5fd82c1@xhv46.dial.pipex.com>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-05-04T00:00:00+00:00
List-Id: <comp.lang.ada>


Nick Roberts said

<<It seems to me that a representation clause would be the much the best way
to specify what sort of storage reclamation strategy is applied to a
storage pool. I would (quite strongly) suggest that full reclamation ought
to be the default, with agreed-upon clauses for selecting other strategies.
There would surely be an option No_Reclamation to switch garbage collection
off completely, for those occasions when it was required.

I would greatly appreciate opinions on this.>>

If you were designing the language out of the blue with no history, this is
a reasonable position (it is the position adopted by Algol-68, Modula-3,
and Java, to name languages that are of a comparable semantic level to Ada).

However, at this stage, no implementor is likely to make a change like
this, since it would disrupt the existing user base too severely. I would
crtainly think that a configuration pragma that specified the default
pool for all access types as being the GC one would be quite appropriate.

Note in all this discussion the need for another important pragma which
is something like

   pragma Storage_Finalization (type-name)

This says to the compiler for a controlled type that the finalizatoin routine
is there only for storage reclamation (the normal case) and that thus calls to
it can be eliminated in a GC environment.

Actually this pragma is useful in a non-GC environment for inhibiting
silly finalization overhead and calls on objects that are allocated on
the outer level heap. Unlike C++, Ada takes finalization seriously, so
it ensures that finalizatoin must occur for all objects. In C++, destructors
are not called for outer level heap objects at the termination of the 
program. In Ada they are. The Ada approach is much cleaner,. and the C++
feature has surprised more than one programmer, but in 99% of real cases,
the C++ approach is what you want, since the destructor is there only to
free storae, and it is silly to waste time freeing storage just before
you free the entire heap!