Re: Ada GC

stt@copperfield.camb.inmet.com (Tucker Taft)
13 Feb 1996 00:27:11 -0500

          From comp.compilers

Related articles
[17 earlier articles]
Re: Ada GC kennel@msr.epm.ornl.gov (1996-02-09)
Re: Ada GC kweise@pluto.colsa.com (1996-02-09)
Re: Ada GC dewar@cs.nyu.edu (1996-02-10)
Re: Ada GC boehm@parc.xerox.com (1996-02-13)
Re: Ada GC yanowitz@mcet.edu (1996-02-13)
Re: Ada GC kelvin@cs.iastate.edu (1996-02-13)
Re: Ada GC stt@copperfield.camb.inmet.com (1996-02-13)
Re: Ada GC rfg@monkeys.com (1996-02-13)
Re: Ada GC boehm@parc.xerox.com (1996-02-14)
Re: Ada GC jsa@organon.com (1996-02-14)
| List of all articles for this month |

From: stt@copperfield.camb.inmet.com (Tucker Taft)
Newsgroups: comp.compilers,comp.lang.ada
Date: 13 Feb 1996 00:27:11 -0500
Organization: Intermetrics, Inc.
References: 96-02-086
Keywords: Ada, GC

Matt Kennel (kennel@msr.epm.ornl.gov) wrote:


: Yes, I think the fact that the same wasn't done in the Ada95 design
: process, that it wasn't a big priority, was indeed "cowardice" as Dr
: Baker said.


Anyone who would accuse the Ada 9X design team of "cowardice" was not
present during the process ;-).


It is true that we didn't make garbage collection a priority, but we
did lay our professional reputations on the line for several other
features that I believe even Henry Baker likes. So let's not talk
about bravery or cowardice. Garbage collection was simply not a
priority.


As time goes on, priorities change, what is the state of the art
becomes the state of the practice, what is the state of the practice
becomes old and boring, etc. Our goal is to make sure that Ada keeps
adapting as appropriate. Often this can be done through tools and
implemtation approaches, without having to disturb the fundamental
syntax or semantics of the language. As it turns out, both Ada 83 and
Ada 95 are very supportive to full garbage-collected semantics,
presuming one finds the resources and incentives to implement it.
This is demonstrated by our success in creating a fully interoperable
implementation of Ada/Java, taking full advantage of the underlying GC
in existing Java VM implementations.


It is silly at this point to try to rewrite history to say that many
people were clammering for GC in Ada, and we were all convinced that
GC was the future, but cowardice prevented us from tackling it.
Personally, I still believe that GC is a bit like variant records. GC
is very useful, but it doesn't feel to me like the ultimate solution
to the storage management problem. I believe that there is probably
some clever approach out there that gets the predictability and
efficiency of stack-based allocation, with the flexibility of GC, in
the same way that type extension (or equivalent) is an efficient and
flexible replacement for variant records.


Henry Baker has in the past mentioned "linear logic" and similar
approaches which allow lower levels to return objects to upper levels,
without introducing the nondeterminacy of arbitrary garbage
collection. Hermes, aka "Nil", is a language that built the notion of
handing off the unique reference to an object into its fundamental
semantics. Something like this seems to have a lot of appeal, both
for efficiency and flexibility, but also for proving programs correct
(aliasing makes proving programs much harder -- handing off references
nicely avoids aliasing).


The next big language design breakthrough may be in translating some
of the ideas of Hermes and linear logic into a storage management
approach applicable to "mainstream" programming languages.


--
-Tucker Taft stt@inmet.com http://www.inmet.com/~stt/
Intermetrics, Inc. Cambridge, MA USA
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.