[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The GH interface. (was: Patch for gh.h)
From: |
Neil Jerram |
Subject: |
Re: The GH interface. (was: Patch for gh.h) |
Date: |
02 May 2001 22:13:15 +0100 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
>>>>> "Marius" == Marius Vollmer <address@hidden> writes:
Marius> Yes. What do people think of the GH interface, in
Marius> general?
GH is advertised in the manual as being the `portable' Guile
interface. I think this is wrong. Given that the SCM type is part of
GH, and considered to be portable, all of the functions in libguile
that define Scheme primitives, with signature `SCM scm_foo (SCM ...)',
are equally portable. With a little work, we could easily go further
and design portable interface equivalents for things like
scm_internal_catch and scm_internal_dynamic_wind.
In other words, if portability was the issue, GH could include very
much more than it is currently described as including. And more or
less the same argument applies to the view of GH as being the `long
term stable' interface.
So, the only way that I can make sense of GH is to think of it as the
simplified interface to use for a very limited class of extensions.
Namely, extensions where all you want to do is define some new
primitives and then either REPL or evaluate expressions from time to
time, and where the primitives are limited to dealing with basic data
types (numbers, strings, vectors and list structure).
Unfortunately, this characterization of GH makes it much less useful
than if it was the portable, stable and fully functional equivalent of
the scm_ interface.
Does this mean that we should add stuff to GH to make it more
functional? IMO, no. The basic problem here (for GH) is that the
vast majority of the scm_ interface is _already_ portable and stable,
and so there's no value for GH to add. If we tried to make the GH
interface functionally equivalent to the scm_ interface, the vast
majority of GH would be a duplicate with no extra value in it.
Therefore, if GH didn't already exist, I wouldn't invent it. Instead,
I'd
- invent a macro SCM_INTERNAL, and use it in libguile header files to
mark everything not considered portable, stable and appropriate for
external use (then Guile would #define SCM_INTERNAL, but
applications should normally not do so)
- design and add portable equivalent scm_ interfaces for the few
things like scm_internal_catch that aren't naturally portable and
stable already.
Given that GH does exist, I think we should continue supporting it,
but get the documentation right, and probably not extend it.
Neil
- Re: The GH interface. (was: Patch for gh.h), (continued)
Re: The GH interface. (was: Patch for gh.h), Chris Cramer, 2001/05/02
Re: The GH interface. (was: Patch for gh.h), Martin Grabmueller, 2001/05/02
Re: The GH interface. (was: Patch for gh.h),
Neil Jerram <=
Re: The GH interface. (was: Patch for gh.h), Marius Vollmer, 2001/05/08
- Re: The GH interface. (was: Patch for gh.h), Neil Jerram, 2001/05/13
- Re: The GH interface. (was: Patch for gh.h), Neil Jerram, 2001/05/13
- Re: The GH interface. (was: Patch for gh.h), Rob Browning, 2001/05/13
- Re: The GH interface. (was: Patch for gh.h), Dirk Herrmann, 2001/05/14
- Re: The GH interface. (was: Patch for gh.h), Lars J. Aas, 2001/05/14
- Re: The GH interface. (was: Patch for gh.h), Neil Jerram, 2001/05/14
- Re: The GH interface. (was: Patch for gh.h), Neil Jerram, 2001/05/14