[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: |
14 May 2001 19:48:08 +0100 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
>>>>> "Dirk" == Dirk Herrmann <address@hidden> writes:
Dirk> I think the major point about the GH interface is the
Dirk> following idea:
Dirk> GH is meant to be an interface that is portable across
Dirk> different implementations of scheme interpreters.
I agree that this has been _one_ stated aim of GH, but the other
equally strong (or stronger) message from the documentation has been
that GH is the interface that application developers ought to use
(irrespective of whether they hope to run their application one day
using an alternative interpreter). Given the strength of this
message, I think we should avoid creating trouble for developers who
have tried to follow it.
Dirk> In other words, anything that is not portable across scheme
Dirk> interpreters, for example the handling of macros,
Dirk> throw/catch mechanisms etc. _can_ not be put into GH. That
Dirk> is, using GH as the "This is stable in guile" indicator will
Dirk> compromise the above idea.
Well I don't see a conflict here, as I think that throw and catch are
perfectly portable. (I.e. given gh_call_with_current_continuation,
one can write a portable implementation of gh_catch and gh_throw. A
particular interpreter such as Guile may choose to implement gh_catch
and gh_throw more efficiently.)
To the extent that any such conflicts arise, I'd say that we should
drop the "different interpreters" angle and leave that to a different
project. (I think this agrees in part with your view.)
Dirk> I stand by my proposal: Get rid of GH in guile. If people
Dirk> think that such a thing as a GH interface makes sense, this
Dirk> should be a different project. It should be a different
Dirk> project, because developing it from within guile will always
Dirk> give a guile centric point, and will not help to achieve the
Dirk> goal to be portable across different implementations of
Dirk> scheme. IMO, only those that are familiar with different
Dirk> schemes should be working on GH.
If GH was primarily a "multiple interpreters" interface, I would agree
with you. But, in practice, it isn't; it's an interface that we have
advised Guile developers to use and which a fair number of them are
using.
Also, the way I see it, the only difference between what we will end
up with under my proposal, and what we will end up with under yours,
is in naming conventions: in mine, the advertised interface will use
prefix gh_, in yours it will use scm_, but the functionality would be
the same. I just think that, given the choice between standardizing
on `scm_boot_guile' or `gh_enter', it's nicer for developers who have
followed the documented advice if we choose `gh_enter'.
Dirk> And finally the most important argument: GH is a super ugly
Dirk> prefix :-)
I completely agree with you here; but I think we have to let other
considerations outweigh the ugliness.
Dirk> Best regards, Dirk Herrmann
Regards,
Neil
- Re: The GH interface. (was: Patch for gh.h), (continued)