This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: hook? primitive
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