Re: 1.6.0 and guardians

[Dirk Herrmann]

On 4 Sep 2001, Michael Livshin wrote:

> Dirk Herrmann <address@hidden> writes:
> 
> > since we are approaching 1.6.0, I suddenly remember a point that might be
> > important for 1.6.0:  Michael has done a great re-implementation of
> > guardians as it became clear that Dybvig's definition of guardians has
> > some weak points.  In that re-implementation round, however, Michael has
> > introduced two kinds of guardians for experimental reasons.
> 
> not really for experimental reasons, but for completeness.  it's no
> big deal keeping both kinds, and I can imagine situations where each
> kind is useful.
> 
> > IMO, we should revise the interface or at least add a note about the
> > current interface to be experimental.
> 
> I'm rather of the opinion that the less done with that thing, the
> better.  I wonder who uses it.

Well, this is exactly an argument against making it an official part of
the API :-)  IMO, guardians are a very useful concept, and in the long
term we should provide a consistent interface for using them.  Dybvig's
API is quite nice, and your 'greedy' guardians form an implementation that
uses the same API but removes the inconsistencies without restricting
usability in any practical situation:  I can't think of any practical
situation where one would want to register an object twice.  The
point of registration for an object would typically be the point of
construction.  Everything else doesn't seem to be very logical.  Further,
objects in cyclic dependencies also don't make sense in the finalization
context.

However, the distinction between greedy and non-greedy guardians seems
unnecessary.  As you ask for yourself:  Who uses it?  We shouldn't bloat
guile with unnessary features and make them official:  Someone _could_
actually use them in a situation where a different solution would make
more sense.  Then, again, we have to change an official API and break
people's code without having them warned before.  We should avoid that.

Further, there are (IMO) some weak points about the current interface:  
Instead of having a throw_p parameter for the function scm_guard, a
separate scm_guarded_p predicate seems cleaner to me.  Destroying of
guardians is also a functionality that I can't follow.  Thus, I consider
the following user interface sufficient for (greedy) guardians:
  SCM scm_make_guardian (void);
  SCM scm_guarded_p (SCM obj);
  SCM scm_guard (SCM guardian, SCM obj);
  SCM scm_get_one_zombie (SCM guardian);
  void scm_init_guardians (void);

Finally, the fact that objects in cyclic dependencies are reported is
quite nice, but simply unguarding them seems wrong to me.  I can see
several possibilities to deal with such objects:  a) Return them from the
guardian as other objects and let the user deal with them, b) return them
wrapped in some special smob object to indicate their specialness to the
user (disallowing, however, to register such a smob with a guardian) c)
just keep them guarded forever d) have some special system wide list
for these objects where such an object gets transferred to if it is
detected - then the user can from time to time fetch out these objects and
decide what to do about them, like breaking the cycles.

But, I remember that we did not agree about this issue before...  
However, all that I am suggesting for the next release is, that we mark
the guardians API as unstable, indicating that it could be subject to
changes.  Maybe this is the point where one of the maintainers should
actually put on the maintainer hat :-) and take a decision between our two
positions.

Friendly regards,
Dirk Herrmann