Re: hook? primitive

[Greg Badros <gjb@cs.washington.edu>]

Mikael Djurfeldt <mdj@mdj-pc.nada.kth.se> writes:

> Greg Badros <gjb@cs.washington.edu> writes:
> 
> > Wed Sep  8 09:18:32 1999  Greg J. Badros  <gjb@cs.washington.edu>
> > 
> > 	* feature.h, feature.c (scm_hook_p, scm_hook_arity,
> >  	scm_hook_length): Added these predicates, and use scm_hook_p in
> >  	other -hook* functions for validating the object.
> 
> Thanks.
> 
> But are all of these really necessary?  I think we should be a bit
> careful with adding new primitives.

They are if you believe in abstraction.  Guile has to hide the
implementation of the hooks, and you can definitely imagine wanting the
user to be able to query how many arguments a hook requires, or how many 
procedures are already in the hook (e.g., for testing after removal
whether it's empty -- I first had it as scm_empty_hook_p, but the more
general version was even easier to write and provides more information.

> scm_hook_p should be added, but is it really useful to ask about the
> arity and length of a hook?  What's the use of knowing the arity of
> the hook if you don't know how to call it?
> 
> Is it really useful in practice?

Yes, most definitely.  I need empty-hook? in Scwm for knowing whether I
should XSelectInput on MotionNotify events or not.  And the arity is
essential for supporting a UI that permits interactively adding
apropriate procedures to the various supported hooks (we can filter the
potential procs based on their arity matching the arity of the hook
we're manipulating.)

> (I added first class hook because I wanted it to be easier to manage
>  hooks (putting them in data structures, like a fluid etc) but now I
>  almost regret it.  They seem to require an unreasonable amount of
>  support in the implementation.)

Hooks are an important part of an extensible embeddable interpreter.  I
don't think you should regret this move-- it makes things more
consistent across client applications that choose to use guile.

Thanks,
Greg