[gclist] Re: gclist-digest V1 #41

[Jerry Leichter]

| How does one add garbage collection to a *language*?  Suppose the C++
| standard say, "an implementation of C++ shall support gc".  Can you
| write a test case that determines whether an alleged implementation
| obeys the rule?
| 
| IMHO, gc is an implementation issue.  When we say "Lisp has garbage
| collection, Pascal does not", we really mean "Typical implementations of
| Lisp have gc, and if you want to sell a Lisp compiler, you'll be
| embarrassed if you don't have it, but typical Pascal compilers don't
| have it, and you can therefore get away with out it."
| 
| To put gc in a *language definition*, one would need a model of storage
| usage that is far more detailed than is typical.

What this mainly proves it the poverty of "typical" language descriptions.

There is, fortunately, some precedent:  The definition of Scheme *requires* that 
tail recursions be implemented so that the stack doesn't grow.  The statement is 
made informally - the fact that there *is* a stack is usually considered "part 
of the implementation", rather than part of the language, so it's hard to be 
specific about how stack manipulation must be optimized!  Nevertheless, all 
knowledgeable readers of language specifications make certain assumptions about 
the implementation of local variables.  A C implementation that allocated heap 
memory instead of stack frames, and never freed them, would certainly meet all 
the written requirements of the C specification.  However, no one would accept 
such an implementation.  We sweep it under the rug as a "quality of implementa- 
tion" issue, but that's only possible because no one would consider doing such a 
thing.  If, in fact, there were C implementations being sold that did this, 
there would soon be a proposal to modify the specs to forbid it.

C (and most other modern language specifications) are written in terms of the 
actions of an idealized machine; actual implementations must, in some sense, 
mirror the idealized machine, at least at certain points during execution.  The 
idealized machines usually don't explicitly include a dynamic memory resource.  
It would be no big deal to add such a thing.  Details will need work - this is 
exactly where the issues discussed earlier on when destructors will be executed 
(based in turn on when "garbage" will certainly be collected) could be dealt 
with in some way beyond mere hand-waving.
							-- Jerry