Re: GC interface (was Re: Scheme hooks <-> C hooks)

[Keisuke Nishida <kxn30 at po dot cwru dot edu>]

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

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

I didn't say anything about combining two hooks.  Sorry about the confusion.

My point was, "Why does Guile need to provide a general C hook facility
in spite of having a general Scheme hook facility?"  The user may use
Scheme hooks in their applications, so I didn't imagine situations where
they needed to use C hooks.  I understand your opinion if the C hook is
not part of the API.

The reason I didn't like generalizing the C hook was because I thought
it was too general.  If GC is the only part where C hooks are needed, we
can minimizing the number of requisite functions by specializing the C
hook facility for GC.  I agree with that generalizing things is a good
thing, but I think it is not necessary to begin with.

In general :), and IMHO, a programmer should try to minimize the number
of functions at the beginning of programming, as long as she is not sure
that generalization is really necessary.  She should write a minimum
facility at first, and if it happens later that generalization is
necessary to expand the program, then she can rewrite the original
implementation at that time.  Writing a general facility from the
beginning tends to make the program more complex than necessary.

Of cause thinking of the future is also important, so what is important
is interface rather than generalization.  As long as a program has a
good interface, it is easy to change the internal data structure by
making it more general (as known as abstraction or encapsulation).

About the C hook, I think it is a kind of special facility for GC, since
we already have a more general Scheme hook.  So if I were you, I would
write a special hook only for GC and provide interface functions
scm_gc_hook_add and scm_gc_hook_remove.  If it happens that more C hooks
become necessary, we can generalize the data structure without changing the
interface.  If it doesn't happen, nothing happens-- we can keep it simple.

If you are writing a general C function library (like Glib), it is great
to write the C hook facility.  But Guile is not.  Moreover, Guile has
Scheme hooks that can be used in most cases.  The need of GC hooks are
special, and since C hooks are so easy to implement, I don't think there
is necessity to write general functions.  If you have another special
case, you can even simply add a different set of hook functions.  I
don't think Guile will have more than five special cases.  If it has,
then you can write general functions *at that time*.  I thought the C
hook was an unnecessary generalization for now.

Your (I guess) generalized code have sometimes helped me, though :)
But I think generalization is not necessary until it becomes actually
needed.  What is necessary is a good interface.  As long as a program
is written with a good interface, it is not hard to modify it later.
Other stuff like generalization or optimization can be done time to time.

Thus, a program grows an unorganized way...  Sometimes it is necessary
to organize it by changing function names, generalizing some code, and
dividing them into modules.  But I like it better than a well-organized
huge project.  So I like to see that Guile has some confusing code with
it right now; but it's about the time to organize them.

Just my coding policy, though.  If you have a different policy, that's
fine.  I don't have any problem with generalized functions :)  So I
really don't want to waste your time discussing this concern.  I feel
a little guilty of causing this discussion...