Re: thanks

[mstachow at alum dot mit dot edu]

"Greg J. Badros" wrote:
> 
> But even in Scwm there are tons of uses of the scm_ interface (and I've
> done everything I can to use gh_ whereever possible).  I've kept a list
> of the extensions needed the gh_ interface to permit Scwm to avoid using
> the scm_ functions altogether. The list is below (and also in the Scwm
> package as scwm/doc/dev/Guile-gh-needs).  I'm in favor of extending the
> gh interface where it makes sense.

It's important to remember that the gh_ interface is intended to be
implementable by other Scheme interpreters, so that applications can
(in theory, anyway) embed a Scheme interpreter but not have to decide
which one. Thus, anything that exposes Guile internals or which is
non-R4RS/R5RS would not be appropriate to put in the gh_ interface.

This is unfortunate because one thing that almost any rich Guile
application wants to do is expose new primitive datatypes, and it
is not clear if there is any way to expose that functionality in
a way that is portable among interpreters.

Of course, the protability requirement of th gh_ interface in this case
seems to conflict with it's purpose as a relatively small but featureful
interface to Guile for application developers. Would it be better
to say, "If you want to do certain advanced things, use the scm_ interface,"
to give up on portability to other interpreters as a goal for the gh_
interface, or to add an extension the gh_ interface, perhaps ghx_, that
is Guile-specific?

 - Maciej