This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: thanks


mstachow@alum.mit.edu writes:

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

I'd say give up on portability where it conflicts with making guile
more useful. One of guile's big strengths (as other people have
attested) is the ability to create new scheme objects and let the
system handle them; this probably won't ever be done in a consistant
way across different schemes due to the differences in core
implementation. I really think that we should aim to have one
conceptual hierarchy that applications programmers can use to embed
guile, which would keep things from being confusing or annoying, and I
don't think scm_ is that hierarchy, since it severly constrains the
kind of changes you can make to the core without totally breaking
compatability (this is even more annoying than having to remember
which of half a dozen prefixes a function belongs to). 

-- 
Greg

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]