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:
> 
> > > I'm not convinced that hook-arity is useful enough to balance the
> > > costs of increased complexity.
> > 
> > But the printable form even includes the arity in it.  The bottom line
> > is: users of guile are going to use:
> > 
> > (cadr some-random-hook)
> > 
> > to get at the hook arity.  To provide a reasonable abstraction of hooks, 
> > that implementation detail needs to be hidden behind a provided
> > procedure.
> 
> Yes.  During the move from the old to the new interface we had a
> representation which was accessible from the Scheme level.  (The old
> interface was written in Scheme.)
> 
> Since we have removed the old interface, we can now modify the
> representation to be a real type.

And that move is good, for sure.

> > P.S.  What complexity?  It's a simple accessor primitive that can be
> > orthogonally ignored, if desired.
> 
> I'm trying to adhere to a policy of only adding useful primitives in
> order to keep the total size down.  One more or less may not matter.
> The real problem is that if you say "It's a simple accessor" too many
> times, Guile will grow too much.
> 
> In my view, Guile already is too complex.  I think we should remove
> primitives instead of adding new.  :)
> 
> Note that more primitives means
> 
>  * a larger libguile

Or, more code already written and tested that doesn't need to be
re-implemented by the clients of the Guile library.  (Hooks are
important to the way people currently write extensible embedded
applications).

>  * a heavier manual

Better exercise.

>  * longer reading time and more to think about

An accessor is nothing to think about.

>  * more administration for the interpreter

Sure.

>  * more memory usage

But again, it saves re-implementation if it's generally useful enough.

To sum up, where are we at?

I think we *really* need hook-empty?, and a more general version from
which hook-empty? could be written would be almost no worse in terms of
the downsides you list above (and hook-empty? would then be written in Scheme).

I can live w/o hook-arity as I could always use an object property on
the hook to store this (and potentially more useful) information about
what procs make sense to add to the hook.

Thanks,
Greg