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: Creating hooks from C


Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:

> scm_create_hook is not beautiful, I consider it broken after this
> discussion.  It should not be encouraged to write code that depends
> on the kind of side-effects that scm_create_hook causes.

I think this is an exaggeration.  You can't call a correctly written
abstraction of the necessary steps involved in creating a vanilla
application hook "broken", and it's not a question of side-effects
but the main purpose of the function.

The function is *not* intended as a means of making hook objects.
It is intended to create an application hook.

Just as it is wrong to use gh_new_procedure to create short-lived
primitive procedure objects (which doesn't exist in Guile, btw), it is
wrong to use scm_create_hook to create short-lived hooks.

> We all now know pretty well what scm_create_hook does.  But who did
> before?  From time to time we get messages on this list about guile
> applications with increasing memory usage.  This can be as nasty a
> bug to find as when something is not protected.  The only difference
> is, that it is not as fatal as the other way around, but this
> increases the chance that people put less effort into looking
> closely into it, meaning that such bugs will live longer.

We should document how to use scm_create_hook correctly.

The purpose of scm_create_hook is documented in the NEWS file, but it
could have been more clear.  At least, I should have mentioned the GC
protection there.

I don't consider scm_create_hook as being sloppy with GC protection.
Generally, Guile is not sloppy about this.  Increasing memory usage is
very probably not due to Guile or its interfaces.  [Exception: Some
parts of GOOPS are not complete in this respect.  I have not yet had
time to insert weak links at critical places in the network of
classes, generics and methods.]

> I don't think that removing scm_create_hook will reduce usability in
> a noticable way, except, obviously, for the temporary pain to
> replace calls to it, but this is not really a point about usability.
> With the upcoming SCM_DEFINE_HOOK it will be really difficult to
> find places where it makes sense.

Here we need to consider the purpose of the snarf macros: Their main
purpose is to implement Guile.  *Some* advanced applications have set
up the snarfing mechanism.

<Maintainer>
The snarf macros should not be considered as a part of the Guile API
proper.  We cannot assume that a Guile application author have access
to them.
</Maintainer>

In an application extension language the operations of adding a new
primitive and adding a new application hook are central, and both
should be represented by a single function call.

Also,
<Maintainer>
C macros are BAD.  They make it harder to edit and read code.  They
cause the compiler to output more code.  They decrease maintainability
and make debugging by stepping through a program harder.

We should use functions instead of macros whenever we can.  There are
a number of reasons why we use macros to the extent we do, for example
efficiency or being systematic (SCM_GUARDIANP is not time critical,
but since all type predicates are macros, the guardian predicate is as
well).  But if we can, we should avoid them.
</Maintainer>

> [quoting from another mail from Mikael:]
> > In fact, the operation of binding a Scheme variable to a named hook
> > from C is likely to be much more useful than creating a "temporary
> > hook" from C.  That operation is likely not to be useful at all, which
> > is the reason why it was not provided.
> 
> Actually, it is:  scm_make_hook does exactly this.

scm_make_hook is a Scheme primitive.  On the Scheme level, everything
is governed by the GC.  An application needs to be able to rely on the
fact that the hook lives when it calls scm_c_run_hook.

However, I *can* imagine that one might want to store a hook in a
smob, etc.  Then it is possible to use scm_make_hook.

> Following your argument that minimizing the number of entries into
> libguile is also an important goal, removing scm_create_hook is also
> a step in the right direction :-) Moreover, the proposed full
> separation of object creation and binding would also reduce that
> number of entries: A very small number of binding functions that
> handle the environment and module stuff and work on any kind of
> object, plus the object creation functions for each type.  All kinds
> of 'mixture' functions can be removed.

No.  "Mixture functions" which implement operations common to the
application writer are needed to make Guile easy to work with.

> Conclusion:  scm_create_hook should be left as it is, but deprecated.  

Sorry, but I think we have reached a kind of dead-lock in the
discussion, so I say

<Maintainer>
Guile should provide a single function call which abstracts what an
application writer needs to do when creating the typical standard
application hook.
</Maintainer>

Note, however that I don't say anything about it's name or in which
API it resides.  Also, I'm prepared to modify this statement the day
we come up with a completely orthogonal, easy-to-use system separating
binding and object creation.

Just as the GH interface provides a single call to create a new Scheme
primitive, the GH interface could provide a single call to create a
standard application hook...  In my interpretation, GC protecting it
belongs to "what an application needs to do", however, so I'd prefer
if the name reflects this, meaning it should not look too similar to
other functions which create objects with bindings.

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