SMOBs (was: Re: mildly incompatible change)

[Jim Blandy <jimb@red-bean.com>]

I think you have smobs basically right.  The are document, in a sense,
at http://www.red-bean.com/guile/docs/data/data_toc.html.

The CALL method is pretty interesting; Roland McGrath and I did a
little Scheme interpreter in 1991 that had something very similar.
However, I tend to think it's better to just add a completely separate
tag for foreign functions; I'm not sure it's so good to make ordinary
data objects callable that we should make it so easy.  If I really
enjoyed wild linguistic hedonism, I'd be using Perl. :)


> At first, I used a single `destroy' the way I assume the smob `free'
> function works.  Later, I realized that the destructor might want to
> call Lisp code, which shouldn't happen while any mark bits are set.
> So I split object destruction into `sweep', which is called during
> gc_sweep(), and `destroy', called when it is safe to invoke user
> code.

I hadn't thought about that.  The whole destructor question is really
pretty hairy; witness the discussions that flare up on the GC list
periodically.  The destructor model I really like is Dybvig's
Guardians:

    @inproceedings{Dybvig:guardians,
    author = {R. Kent Dybvig and Carl Bruggeman and David Eby},
    title = {Guardians in a generation-based garbage collector},
    booktitle = p:pldi93,
    pages = "207-216",
    month = jun,
    year = 1993,
    annote = {Introduces guardians and describes the implementation of
    guardians and weak pairs in Chez Scheme.}}

(I wish I could find on-line PostScript, but I can't.)


> It was also useful to allow the sweep method to return a value
> indicating that the object was still referenced implicitly and should
> not be freed yet.  (I see the smob `free' returns a value; can that be
> used to prevent destruction?)

This I'm not so sure about.  If the object is live, you should tell
the GC about the pointers to it.  It sounds to me like you could get
the same effect more reliably through other means.