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

[Neil Jerram]

>>>>> "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