Re: Idea for culling the core of guile to a neater system

[Greg Harvey <Greg.Harvey@thezone.net>]

Keith Wright <kwright@tiac.net> writes:

> > From: Greg Harvey <Greg.Harvey@thezone.net>
> > 
> > Actually, the current gc is pretty removable. As far as I've seen,
> > code only calls the mark stuff (there may be someone playing behind
> > ...
> > The biggest problem, though, is that it will require rather large bits
> > of guile to be rewritten. Not that this would be a bad thing, because
> 
> I don't understand, these seem contradictory.  How can GC be
> removable if it requires large amounts of re-write?  What
> would need to be re-written if the GC changes?

I think replaceable is probably a better way to describe
it. Decoupling the gc from guile into a useful allocation library, and
then building guile around that will require a lot of code around
guile to be changed, as opposed to just modifying guile's gc, which
only needs to assure that the gc actually works, and that it provides
the SCM_GC* macros (the working bit is the harder requirement ;'). It
depends on how general it should be, I guess; it could require
anything from just moving the mark & sweep routines for each type of
object outside the gc and registering them in initialization, to
completely changing the way objects are represented (which is probably
the most useful alternative, but does require more work, both with the
gc, and with making the rest of guile play nicely, since a lot of the
tagging things might not make sense, or at least not be easy to force
the gc library into using). I'm sure that it's possible, but it could
be a large undertaking, and may not be the most useful thing, since
there already exists a good plugin gc for c & c++, so the gc code
itself might not be all that useful outside of guile. To make it more
general would probably also slow it down, which isn't really something
that's desirable.

-- 
Greg