This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Dumping and restoring side-effects
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