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

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