[gclist] What to say about GC.

[Jim Blandy]

I think it doesn't make sense to call GC either "transparent" or
"bug-prone" without specifying for whom you're speaking.

If you're just using a GC'd language (i.e., Scheme), GC is a
life-saver.  It relieves the user from many allocation policy
decisions, thus making the allocation policy easier (or trivial) to
follow.  It approaches the "trouble-free" vision that started this
thread.

If you're just implementing a GC-ing interpreter in an uncooperative
language, or a native code compiler, keeping track of all your roots
can be a pain, but it's an accepted complexity, once you've chosen to
use GC at all.  Since all the code which must co-operate with GC is in
one place, and maintained by people talented enough to implement a
programming language in the first place, you can make some simplifying
assumptions, and rely on the implementors' expertise.

However, problems arise when you have to export an interface to GC for
use by a non-GC-friendly language, like C.  In Emacs, the GC interface
is a disaster --- a bug emitter.  Conservative collectors help, but
it's still a stretch to call them "error-free" or transparent.  You do
have to remember they're there.  Using GC in an uncooperative language
blurs the boundary between "GC implementor" and "GC user", because you
must make explicit provision in your code to keep the GC happy.

I think part of the noise in this discussion stems from the fact that
people haven't specified which side of the interface they're talking
about.  Let me offer some guesses: Fergus Henderson wrote as a pure
user of a GC-friendly language, like Scheme.  Will Clinger has
implemented Scheme systems in which the foreign function interface
wasn't as important.  Tom Lord is working on a Scheme interpreter
designed for use as a generic extension language library for C
programs, so he sees the worst of all worlds.