Re: Dumping and restoring side-effects

[Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>]

On 4 Feb 2000, Greg J. Badros wrote:

> Neil Jerram <neil@ossau.uklinux.net> writes:
> 
> > I wrote:
> > 
> >    Your freshener approach sounds compelling to me.  The only issue I
> >    have with it is that I don't see why you need to extend the SMOB
> >    function table.  Why not just use a hook to store a load of freshener
> >    thunks, to be executed after the program is restarted?
> > 
> > Sorry - I misunderstood that you are not proposing to extend the basic
> > set of SMOB functions.  Even so, I think that the question is still
> > valid.
> 
> 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.
> 
> 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.  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.

The question is, how such a hook would be implemented.  You would not have
to store a thunk for each SMOB, but rather could have one single thunk
working on a list of SMOBS of one type, which would reduce the
amount of memory required.  Further, the problem of how to order the
freshening actions can also be easily addressed this way and gives more
freedom compared to a solution that is hard coded into the SMOB structure.

Best regards,
Dirk Herrmann