Re: [guile/scwm] SCM_HOOKP changed?

[Marius Vollmer]

P Pareit <address@hidden> writes:

> Hey,
> 
> I have a lot of code depending on SCM_HOOKP, has SCM_HOOKP changed
> in any way?  I also seen it is not documented, so I guess it should
> not be used, is scm_hook_p the right alternative?

No, the problem is something else.

SCM_HOOKP returns a C boolean, that is, either 0 or 1.  scm_hook_p
returns a Scheme boolean, either SCM_BOOL_F or SCM_BOOL_T (which are
both true in the C sense).

In your program belowe, error_hook is a variable, not a hook.  Both
SCM_HOOKP and scm_hook_p returne their variant of false, but you test
the return value of scm_hook_p in the wrong way.  You would have to
write

  if (SCM_FALSEP (scm_hook_p (error_hook)))
    ...

(Do not compare directly with SCM_BOOL_F since there might be other
false values, like scm_lisp_nil.)

The reason why error_hook is a variable is because scm_c_define
returns the variable that it has created or reused, not the value that
the variable is initialized with.

The best think to do is probably to use SCM_SNARF_HERE and
SCM_SNARF_INIT, like so:

  #define SCWM_GLOBAL_HOOK(var, name, args, docstring) \
   SCM_SNARF_HERE (SCM var) \
   SCM_SNARF_INIT ( \
     var = scm_permanent_object (scm_make_hook(SCM_MAKINUM(args))); \
     scm_c_define (name, var);)

Guile will support SCM_SNARF_HERE and SCM_SNARF_INIT, I think there is
no way around that.  When possibly, I'll also add
backwards-compatability for SCM__I, etc.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405