Re: 1.6.0 and guardians

[Michael Livshin]

Dirk Herrmann <address@hidden> writes:

> On 4 Sep 2001, Michael Livshin wrote:
> 
> > 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 :-)

by "done with that thing" I meant developing the feature, as opposed
to developing _with_ the feature.  sorry for being unclear.

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

I can.  but we've been through this before. :)

> The point of registration for an object would typically be the point
> of construction.  Everything else doesn't seem to be very logical.

er.  ok.

> Further, objects in cyclic dependencies also don't make sense in the
> finalization context.

yes.  but I can't see anything that can realistically be done to
prevent objects in cyclic dependencies from getting into the
finalization context from time to time.  aside from banning side
effects from the language, that is.

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

well, I implemented the non-greedy variety because the greedy variety,
while being better optimized for common usage, has some pretty ugly
warts.

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

I considered this, but it isn't really any cleaner.  it's also not
thread-safe -- the state of the world might change under you between
checking whether the seat is taken and actually sitting down.

anyway, now that I think about it, the `throw_p' parameter should be
removed.  if you are not sure about an object's ownership, you
shouldn't try guarding it (greedily, that is).

> Destroying of guardians is also a functionality that I can't follow.

here's the rationale, from the NEWS entry:

<quite>
Also, since greedy guarding is, in effect, a side-effecting operation
on objects, a new function is introduced: `destroy-guardian!'.
Invoking this function on a guardian renders it unoperative and, if
the guardian is greedy, clears the "greedily guarded" property of the
objects that were guarded by it, thus undoing the side effect.

Note that all this hair is hardly very important, since guardian
objects are usually permanent.
</quote>

note the use of "are usually" and "hardly very important".  without
the presence of `destroy-guardian!', I would have to dictate a style,
and I'd rather not.

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

I like variant d).

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

I'm perfectly fine with considering the greedy guardians official and
the non-greedy experimental.  neither are currently documented,
anyway.

P.S.  GC finalization is a known thorny subject.  I should have known
      better than getting into this in the first place. :)

-- 
Incrementally extended heuristic algorithms tend inexorably toward the
incomprehensible.