[gclist] Re: gclist-digest V1 #41

[boehm.PARC@xerox.com]

"
| 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.
"

I think there are good reasons both for and against including such things
in language descriptions.  Modelling storage use in enough detail to be
useful is likely to constrain the optimizer significantly.  (SML of NJ and
Andrew Appel's book actually do this, for good reason.  But I think Andrew
also would agree that this is not free.)

If you don't include a detailed model of storage usage (and I think
a C or C++ standard shouldn't),  that precludes a completely formal
requirement for GC.  There's no reason to include such a requirement
in the standard for at least 2 reasons:

1. Not all implementations should support it.  We regularly use a C
compiler for 8051 embedded processors (256 bytes easily accessible
data memory + 64K "external" memory).  GC support doesn't make much
sense in such environments.

2. As Jerry's Scheme example illustrates, informal statements in
standards can be sufficient.  I believe it would be very difficult to make
the Scheme tail recursion requirement precise.  But as it stands, it gets
the right idea across.  As another example, the current C++ draft standard
gives asymptotic running time bounds for STL functions.  I think it's
essentially impossible to define what that means on a modern machine.
(Unfortunately the standard doesn't currently admit to that.)  But those
bounds still convey a very useful informal guideline to both implementors
and users.

Hans-J. Boehm

Standard disclaimer ...

Starting Monday, I expect my email address to be boehm@mti.sgi.com.
I will probably miss some messages to this list in the transition.