This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: GC interface (was Re: Scheme hooks <-> C hooks)
Michael Livshin <mlivshin@bigfoot.com> writes:
> Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
>
> > However, the C hook facility seems generally useful.
>
> yes, but I think there's no need for separate interfaces for Scheme
> and C hooks. you could define things so that you can add both Scheme
> and C procedures to the same hook.
Yes, this is how I originally thought. If we would base the Scheme
hooks on the C hook layer, this would be easy to achieve. It would
also be symmetric to the way many other mechanisms are built in
Guile. Compare, for example, to the way `catch' is based upon
scm_internal_catch.
The GC hooks would have to have some flag which "locks" them so that
you can't add Scheme hook functions.
Probably, the Scheme level hook mutators, such as `reset-hook!'
shouldn't remove the C hook functions, though...
I'm not entirely sure that this is a good idea, however.
> well, it looks like we go in circles
This is my impression of the situation.
I think there are two different issues involved. Maybe we have
misunderstood eachother at certain points.
Terminology:
hook - an object onto which you can hang hook functions
hook function - one of a set of functions in a hook
Scheme hooks - the old "standard" hooks, which are usable from both
Scheme and C, but which only handles Scheme hook
functions
Scheme hook function - hook function represented as a Scheme procedure
C hook function - hook function represented as a C function
C hooks - usable only from C, currently handles only C
hook functions; currently only used by the GC,
but of general utility
1. There's no question that the C hooks are needed. I also hope that
there is no question that we should export them. However it could
be discussed whether they should belong to the standard API or not.
But which compilation unit should export them and which names
should they have?
Keisuke says that we should move them to gc.c and rename them to
have "gc" in their names.
I say "why?".
Keisuke says "because they are only needed there".
And I don't get it, because I see it as an advantage to have this
neat tool available for other kinds of uses, and it feels awkward
to name something which is of general utility in a way that
suggests a more restricted capability.
2. Should it be possible to add C hook functions to Scheme level
hooks?
Keisuke says "is that really needed?". (This is my interpretation
of what he means, although he talks about C hooks in his response.
Please correct me, Keisuke, if I'm wrong.)
In my response I of course got caught by the word "C hooks", and
responded to the question "is C hooks really needed", the answer
of which I would claim is "yes".
I'm not sure I know the answer to question 2. Does someone else?
> and I understand that now is a Very Special weekend wrt GOOPS
> integration, so I'll just shut up.
Well, it was supposed to be that, but there is unfortunately no chance
now...
If I'm right in what I say in this discussion, then this is mostly a
waste of time, but if I've missed something about it and we should
change the C hook interface, then we might as well do it now since
they were so recently added. So I'd say we might as well continue
this discussion to its natural end. (And since we don't know if it's
a waste of time, it really isn't. :)