Re: Dumping and restoring side-effects

[Neil Jerram <neil at ossau dot uklinux dot net>]

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.

   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,

(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.

   Plus at the point where you record that you need to freshen an
   object, that code needs to know what the freshen routine for its
   kind of object is, and it's better to have that code associated
   with the description of those objects, rather than just thrown
   about in the code haphazardly.

In either case, the relevant code exists only in one place.

Regards,

        Neil