Re: Creating hooks from C

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

On 27 May 2000, Mikael Djurfeldt wrote:

> A lot of this discussion is driven by the urge to be systematic.  To
> be systematic is very important, since, if you are, people will be
> able to predict things about Guile and easier remember them.
> 
> If it works that way, being systematic is useful, which is the primary
> goal.
> 
> But it is not useful to provide unnecessary operations, or to split a
> natural abstraction in a certain way, just to be systematic, which is
> not the primary goal.
> 
> Another goal, which is also higher than being systematic, is to
> minimize the number of entries in Guile's interfaces.

I agree that you can be systematic in a way that is not usefull.  Thus, if
an interface is systematic and usefull, this may be what I think of if I
say that it is _beautiful_.

scm_create_hook is not beautiful, I consider it broken after this
discussion.  It should not be encouraged to write code that depends on the
kind of side-effects that scm_create_hook causes.  Now we discuss the
problem what may happen if we don't protect things from within
scm_create_hook any more, but we forget to ask about the other case:  Code
that _expects_ that things are _not_ protected.  We all now know pretty
well what scm_create_hook does.  But who did before?  From time to time we
get messages on this list about guile applications with increasing memory
usage.  This can be as nasty a bug to find as when something is not
protected.  The only difference is, that it is not as fatal as the other
way around, but this increases the chance that people put less effort into
looking closely into it, meaning that such bugs will live longer.

That is the reason why I would put a larger emphasis on being
systematic:  Things that are not systematic will get you some day, because
people tend to 'assume' that it is systematic.

A system that is designed systematically and useful will attract more
users and will cause _confidence_.  I don't think that removing
scm_create_hook will reduce usability in a noticable way, except,
obviously, for the temporary pain to replace calls to it, but this
is not really a point about usability.  With the upcoming SCM_DEFINE_HOOK
it will be really difficult to find places where it makes sense.

[quoting from another mail from Mikael:]
> In fact, the operation of binding a Scheme variable to a named hook
> from C is likely to be much more useful than creating a "temporary
> hook" from C.  That operation is likely not to be useful at all, which
> is the reason why it was not provided.

Actually, it is:  scm_make_hook does exactly this.  Following your
argument that minimizing the number of entries into libguile is also an
important goal, removing scm_create_hook is also a step in the right
direction :-)  Moreover, the proposed full separation of object creation
and binding would also reduce that number of entries:  A very small
number of binding functions that handle the environment and module stuff
and work on any kind of object, plus the object creation functions for
each type.  All kinds of 'mixture' functions can be removed.

Conclusion:  scm_create_hook should be left as it is, but deprecated.  
Since Keisuke's macros will hopefully be integrated in a not so far
future, we will then also have a replacement for the most common usage
pattern.  Up to then, users of scm_create_hook will have to compile with
deprecated functions included.

Best regards
Dirk