Re: thanks

["Greg J. Badros" <gjb at cs dot washington dot edu>]

Greg Harvey <Greg.Harvey@thezone.net> writes:

> mstachow@alum.mit.edu writes:
> 
<snip>

> > 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). 

I agree.  I kind of view the gh_ interface as the application
programmer's interface to guile:  a layer of abstraction that provides a 
clean conceptual interface to guile as an extension toolkit and that
other Scheme interpreters could choose to implement.  Ideally non of the 
low-level guile details should be exposed, not because other Scheme
implementations disagree, but because the application program should not 
need to worry about that stuff.

Greg