guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The GH interface. (was: Patch for gh.h)


From: Dirk Herrmann
Subject: Re: The GH interface. (was: Patch for gh.h)
Date: Tue, 8 May 2001 09:20:27 +0200 (MEST)

On 1 May 2001, Rob Browning wrote:

> Marius Vollmer <address@hidden> writes:
> 
> > Yes.  What do people think of the GH interface, in general?
> 
> When I was getting started with guile, the gh_ interface was after a
> short while a real hinderance.  The problem was that the documentation
> (at least then) made it sound like using any scm_* functions was a bad
> idea, risky, undocumented, and subject to change.
> 
> The problem is that as soon as I was doing non-trivial things in guile
> on the C side (even something as simple as (< x y), I really *neeeded*
> the scm_functions, but in accordance with the warning in the docs, I
> spend a decent amount of time trying to avoid non gh_ functions.
> After a while, I just decided to ignore the docs and started using
> whatever I needed from libguile.  Then I was much happier :>

_Exactly_ my own experience :-)  Seems to be a common pattern.

What, for example, I found missing in GH was:  How can I determine whether
a number would fit into a C integer before I try to convert a SCM number
to an int?  When I as a guile newbie brought this problem up, there was
some discussion about it, but no conclusion was found, most probably
because all problems with the gh interface are just newbie problems:  
After some time, every real guile user seems to switch over to the scm
interface anyway and becomes less interested in improvements to GH.

My suggestion (unpolite and selfish as I am) is to get rid of the gh
interface.  Sounds harsh, but as it has been claimed by others, the scm_
interface has over time become very stable, too.  The lack of functions
scm_car and friends is a special case that could easily be solved.

This is in contrast to what the manual says, that GH is the stable
interface and guaranteed to stay and such.  Well, just another prove for
the fact that you should avoid making guarantees for software.

Best regards,
Dirk Herrmann




reply via email to

[Prev in Thread] Current Thread [Next in Thread]