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:

> > (BTW, if "yes", what should happen with the C hook functions in a hook
> >  when we call `reset-hook!' from the Scheme level?  This is not some
> >  kind of trap... :)
> 
> consider me fallen into the trap then ;).  why should `reset-hook!' do
> anything special in the presence of C hook functions?

When I wrote the above question I thought "this sounds like a trap,
better tell him that it's not"---how wrong I was!  :)

I brought up `reset-hook!' because it is the only mutator where the
Scheme level could influence the C level.  The obvious behaviour is to
remove all hook functions.  There would then not be any way for the Scheme
level to restore the C hook functions.  An alternative would be if
Scheme level `reset-hook!' only removed Scheme level hooks.

Then, what about `hook->list'?  Should C hook functions be excluded,
or should they be first class objects, being represented by a new data
type?  If they are first class objects, then they could be handled by
`add-hook!' and `remove-hook!', but it is questionable how useful this
would be.

My answer to the question if there is something which makes me believe
that Scheme hook functions and C hook functions shouldn't be equal is
this:

There are a number of strange questions which turn up if one tries to
do this.  C hook functions don't do a good job being Scheme objects.
If they aren't objects, there will be "holes" after them (as described
above).  If they are, they will just be passive place holders.

Also, I wonder how useful it is to be able to mix.  The current C
hooks have their clear use in the GC.  It looks like they can be
useful in the unmemoization protocol of the environments when
implementing fancy kinds of optimizations of method dispatch.  (In
this case, they would probably be time critical, btw.)

The typical role of the Scheme hooks is that the application wants to
support executing a bunch of Scheme procedures at certain events.

There doesn't seem to be any connection between the two.

So, while I'm not very much against the idea of merging the two hook
interfaces, building Scheme hooks on C hooks, and allowing to mix
them, I kind of believe that precisely what we have now is useful
enough, and I wonder if a merge is worth the trouble.

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