This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Scheme hooks <-> C hooks


Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> Yes, there are now two kinds of hooks:
> 
> * C hooks, which run C functions.  Operations on these have prefix
>   scm_c_hook_.
> 
> * Scheme level hooks, which run Scheme functions ("ordinary" hooks).
> 
> I added the former primarily because I've instrumented the GC with
> them.  It is not possible to use ordinary hooks for this, and, in
> the GC case, running C functions is exactly what you want.

The reason you can't use ordinary hooks for GC is because they could
break the GC process, right?  So there is no reason for an application
developer to use C hooks other than for GC purpose.

Although C hooks could be in fact generally useful, yet I think it is
safe to limit their usage to GC hooks and force application programmers
to use Scheme hooks.  Actually, most programmers want to use Scheme
hooks rather than C hooks as long as they do not break the application.

I'd like to suggest renaming all scm_c_hook_* to scm_gc_hook_* and
moving them to gc.[hc].  Then, all official API functions will be
scm_gc_hook_add and scm_gc_hook_remove.

> I then considered that such hooks could be generally useful in
> applications, and the fact that we could build the ordinary hooks upon
> this layer.  (I haven't had time to do so, though.  If someone wants
> to do that, it would probably be good to do so.)

I guess this is neither time critical nor memory consumptive part, so
keeping it using Scheme representation is okay and easier to maintain.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]