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: Mon, 14 May 2001 10:46:35 +0200 (MEST)

On 13 May 2001, Rob Browning wrote:

> Neil Jerram <address@hidden> writes:
> 
> (Thanks for the summary.)
> 
> > - the effort to integrate with the change (within the usual
> >   deprecation period, of course) falls more on developers using the
> >   SCM interface than on those using GH, which (by the current
> >   definition of GH) is as it should be.
> 
> I don't have a very strong opinion about which of the paths you've
> outlined we should take, but note that your preferred approach might
> actually imact a lot of end-users too since the impression I've been
> getting is that many of them already came to the conclusion that the
> gh_ interface wasn't sufficient and are already using scm_ functions.
> 
> I do like the idea of clarifing the gh_ interface's purpose, and it
> would be nice if we were able to figure out what we wanted and at
> least document it in 1.6.0.

I think the major point about the GH interface is the following idea:

  GH is meant to be an interface that is portable across different
  implementations of scheme interpreters.

Citing from extend.texi:

  The Guile interface functions documented in this chapter make up a high
  level, portable interface which (we hope) will also someday work with
  other Scheme interpreters, allowing you to write C code which will work
  with any of several Scheme systems.

In other words, anything that is not portable across scheme interpreters,
for example the handling of macros, throw/catch mechanisms etc.  _can_ not
be put into GH.  That is, using GH as the "This is stable in guile"
indicator will compromise the above idea.

I stand by my proposal:  Get rid of GH in guile.  If people think that
such a thing as a GH interface makes sense, this should be a different
project.  It should be a different project, because developing it from
within guile will always give a guile centric point, and will not help to
achieve the goal to be portable across different implementations of
scheme.  IMO, only those that are familiar with different schemes should
be working on GH.

And finally the most important argument:  GH is a super ugly prefix :-)

Best regards,
Dirk Herrmann




reply via email to

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