|[17 earlier articles]|
|Re: Ada GC firstname.lastname@example.org (1996-02-09)|
|Re: Ada GC email@example.com (1996-02-09)|
|Re: Ada GC firstname.lastname@example.org (1996-02-10)|
|Re: Ada GC email@example.com (1996-02-13)|
|Re: Ada GC firstname.lastname@example.org (1996-02-13)|
|Re: Ada GC email@example.com (1996-02-13)|
|Re: Ada GC firstname.lastname@example.org (1996-02-13)|
|Re: Ada GC email@example.com (1996-02-13)|
|Re: Ada GC firstname.lastname@example.org (1996-02-14)|
|Re: Ada GC email@example.com (1996-02-14)|
|From:||firstname.lastname@example.org (Tucker Taft)|
|Date:||13 Feb 1996 00:27:11 -0500|
Matt Kennel (email@example.com) 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
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 firstname.lastname@example.org http://www.inmet.com/~stt/
Intermetrics, Inc. Cambridge, MA USA
Return to the
Search the comp.compilers archives again.