[Top][All Lists]

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

Re: gh_ vs. scm_ Interfaces

From: Martin Grabmueller
Subject: Re: gh_ vs. scm_ Interfaces
Date: Thu, 11 Jan 2001 10:21:40 +0100

> From: Neil Jerram <address@hidden>
> Date: 09 Jan 2001 20:45:09 +0000
> Plus there is the suggestion that the gh interface is likely to be
> more stable.

Another difference seems to be that the gh interface is doing much
more sanity checking, so it is well suited for being used in places
where safety is more important than speed.

> Another consideration ISTR is the idea that the gh interface could be
> implemented by a completely different interpreter than Guile, and that
> therefore, if you wrote an extension using only the gh interface, you
> could plug in any interpreter that implemented the gh interface.
> Realistically, I very much doubt that this will ever happen, so I
> think that we should drop this angle.

The PLT people once started a port of the gh interface to MzScheme
IIRC, but I think they discontinued it.

> In summary, I think we have two options.
> Option 1 is to drop the attempted distinction between the gh and scm
> interfaces, and only retain the gh interface for backwards
> compatibility.
> Option 2 is to keep the distinction between the two interfaces.  But
> this means that we must (i) better define what that distinction is,
> and (ii) make the gh interface complete enough to be useful.  Amongst
> other things, (ii) needs to take into account, and perhaps provide
> equivalents for, the usefulness of macros like SCM_VALIDATE_*, and
> other conveniences of the scm interface such as its snarfing support
> (SCM_DEFINE etc.).

Although access to these macros would be nice, I don't think they
should simply be duplicated with a GH_ prefix.  A good distinction
between gh and scm could be that all gh functions do error checking,
so that the VALIDATE macros are not necessary for safe programming,
and that the scm interface is for people who want the speed and know
what they do.

Thanks for your response,
Martin Grabmueller              address@hidden  address@hidden on EFnet

reply via email to

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