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


Keisuke Nishida <kxn30@po.cwru.edu> writes:

> 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.

Why do you want to rename them to scm_gc_hook when they don't contain
and don't need to contain any GC code?

I think Linus Torvalds is correct when he says that being too generic
is EVIL, but given that strong reasons (being able to break out
guardians and enabling adding similar modules to Guile) has motivated
this kind of hooks, why not expressing them in as general way as
possible (without being more generic than necessary)?

Also, I'm not sure what it is you're suggesting.  Are you saying that
we should not support C hook functions, or are you saying that we
should do this by encapsulating them as a Scheme primitive procedure?

> > 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.

I don't think maintainability is an issue here, but you may be right
that it isn't worth the effort.

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