Re: Dumping and restoring side-effects

["Greg J. Badros" <gjb at cs dot washington dot edu>]

Neil Jerram <neil@ossau.uklinux.net> writes:

> Greg Badros writes:
> 
>    Well, I was wondering about whether the basic set of SMOB functions had
>    any "standard" extension mechanism, and also did query whether dumping
>    is deemed important enough to adopt freshening (or some variant) for an
>    upcoming version of guile.
> 
> Right.  I think that dumping probably is important enough.  (Your
> solution will apply equally well to cleaner mechanisms that we may use
> in the future, such as mmap.)  I don't know about a standard SMOB
> extension mechanism, but as soon as GOOPS is in the core I think the
> answer will be to use that.

Yep;  I've been leaving GOOPS alone so far, but will learn about it when 
it's in the core.

>    The problemn with a bunch of thunks is that there are lots of objects,
>    and the thunk is always the same for a given kind of object.  It'd be
>    redundant to keep a list of thunks, assuming you want the list of
>    objects that need freshening, too.
> 
> You wouldn't need a list both of thunks and of objects.  For example,

I know I wouldn't *need* both, but I think having the list of objects
that need freshening is more generally usefully and conceptually clean.
I'd anticipate wanting that list available even if the thunks were around.

> (define (make-colour-freshener colour-obj)
>   (lambda ()
>     (freshen-colour colour-obj)))
> 
> (define (freshen-colour colour-obj)
>   ...)
> 
> The relevant object is wrapped in the closure of each thunk.  I doubt
> that it's very memory efficient to construct so many closures, though,
> so perhaps your object-list approach is better after all.

I agree. :-)

<snip>

Greg