This is the mail archive of the
mailing list for the Guile project.
Re: Dumping and restoring side-effects
- To: Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>
- Subject: Re: Dumping and restoring side-effects
- From: "Greg J. Badros" <gjb at cs dot washington dot edu>
- Date: 04 Feb 2000 09:38:55 -0800
- Cc: Neil Jerram <neil at ossau dot uklinux dot net>, guile at sourceware dot cygnus dot com
- References: <Pine.LNX.firstname.lastname@example.org>
Dirk Herrmann <email@example.com> writes:
> On 4 Feb 2000, Greg J. Badros wrote:
> > Neil Jerram <firstname.lastname@example.org> 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
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).