Re: Unwanted hook names (was Re: interface reductions)

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:

> On 26 May 2000, Mikael Djurfeldt wrote:
> 
> > Hooks are important and common enough that it should be easy to create
> > them from the application.  Thus, scm_create_hook is a service
> > libguile should provide, in my view.  It should abstract the actions of
> > 
> > 1. creating the hook
> > 2. giving it a name
> > 3. creating a Scheme level binding for it
> > 4. GC protecting it
> 
> I'm a little bit confused about what you mean when saying 'giving it
> a name'.

I mean setting the 'name object property.

> As far as I understood the discussion so far, the concept of names for hooks
> is what actually is to be removed.  But maybe I wasn't clear enough, so I
> enclose my proposed patch below.

In your previous letter, you said you would deprecate
scm_create_hook.  This is what I objected against.

In your patch it doesn't look like you'll deprecate this function
(maybe as a consequence of my letter).  If I'm correct regarding this,
I think your patch is good.

> Regarding the possibility to easily create hooks from the application with
> scm_create_hook:  For the time being, I think you are right.  With
> Keisukes extended set of snarf macros, however, I would say, all four
> (three? still not sure about point 2) points you said above belong to the
> responsibility of SCM_DEFINE_HOOK, which will do all 4/3 points above and
> additionally assign the created hook to a global C value.

It is better that SCM_DEFINE_HOOK is based upon scm_create_hook than
to insert large amounts of code at each invocation.

I think that there generally should be functions behind most snarf
macros.  For example, there are instances where you need to use
scm_make_subr_opt instead of using snarf macros.

> If, in contrast, a hook is not to be assigned to a global C
> variable, then there is no need to GC protect it: Either it is still
> in use, or it is not and may be collected.  It's not a good idea to
> use scm_create_hook for creating temporary hooks or hooks that have
> only a scheme but not a global C binding, since they won't get
> collected.

I think you're right that when the snarf macro is introduced, the GC
protection belongs in the macro rather than in scm_create_hook.

> Thus, for the long term I regard the scm_create_hook at most as a
> helper function for SCM_DEFINE_HOOK, but not appropriate for general
> use.

I think it should be regarded as appropriate.  But, in line with your
reasoning above, we could already now remove the GC protection.