Re: Dumping and restoring side-effects

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

Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:

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

I'm confused how this makes things *easier* on the ordering problem.
The way I see it, if I have a list of objects that need to be freshened, 
I can just go through the object in-order and call their freshening
method.  If I have separate lists, one for each SMOB type, then I need
to coordinate the order in which I call the freshen methods in some
other way.

W.r.t. flexibility, I don't think it's necessary to be able to call an
arbitrary thunk, but it'd be easy enough to let procedures be added to
the list of objects-neeeding-freshening, and just apply those elements
when they are reached (i.e., the freshen routine for a procedure object
is just a routine that invokes that procedure).

Greg