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:

> Right, but in my personal opinion it would make sense to separate the
> concepts of creating an object and creating a global (or
> module-global) binding for an object.  This is because I prefer to have a
> function that makes a subr, and nothing else, and then to create a binding
> for it, in contrast to a beast like scm_make_subr_opt that does it all,
> but controlled by flags.  But this leads us to a completely different
> topic :-)

I agree with you that scm_make_subr_opt isn't a beautiful thing.  It
will surely change in the future.

[Just a side note: It's easy for us to criticize old Guile code.  But
we should note that although much ugly things were included in Guile
early on, quite a lot of *useful* code grew at a faster rate then than
now.  If you have a limited amount of energy, it's not an easy
question how to balance between the striving towards perfection and
"real action".  Also, we have to keep in mind that we now have set up
new standards for the code, and can't blame old code for not adhering
to it...]

But having a function that both creates a primitive and a binding for
it is common and useful enough to warrant a single function performing
these tasks.  I have a lot of experience in writing Guile
applications, and I know that this need occurs now and then.

The same goes for hooks.  Just as creating a named primitive and a
binding for it is natural thing to abstract in a single C function
(since we don't like scm_make_subr_opt, let's think about
gh_new_procedure), the symmetrical case of creating a named hook and a
binding for it is also a natural thing to do.

The fact that procedures and hooks, as other Scheme objects, don't
naturally have names, and that we add the names primarily for
printing and debugging doesn't alter this.

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.

I think my original thought behind protecting the hook in
scm_create_hook is that since the most common situation is that hooks
are run from the C level in an application, they should live forever.

> SCM
> scm_create_hook (const char* name, int n_args)
> {
>   SCM vcell = scm_sysintern0 (name);
>   SCM hook = make_hook (SCM_MAKINUM (n_args), "scm_create_hook");
>   SCM_SETCDR (vcell, hook);
> 
> #if (SCM_DEBUG_DEPRECATED == 0)
> 
>   scm_set_object_property_x (hook, scm_makfrom0str ("name"), scm_makfrom0str (name));
>   scm_protect_object (vcell);
> 
> #endif  /* SCM_DEBUG_DEPRECATED == 0 */
> 
>   return hook;
> }

As Carl and you have noted, we can't do like this.

I suggest we just keep the original scm_create_hook as is.