Re: thanks

[Michael Livshin <mlivshin at bigfoot dot com>]

Miroslav Silovic <silovic@zesoi.fer.hr> writes:

> > gh (excellent initials, those ;) should
> 
> Funny. :)
> 
> > be a collection of useful abstractions that allow you to do what you
> > want, without exposing you to exactly how it's done inside guile.
> 
> I think this is an issue to discuss.
> 
> Many parts of scm_ interface are just straigtforward C bindings of
> RnRS. For example, scm_cons, scm_assq_* etc is just Scheme directly
> translated into C. This seems like a reasonably
> implementation-independant part of the interface. So... Is there a
> point in writing gh wrappers around these? Would it do to just use
> #define to alias scm_cons to gh_cons instead? Or to split scm_
> interface into guile specific (e.g. smob functions) and general
> (RnRS library functions) and document it as such?

yup.

the current partitioning of the Guile API's into "levels" (gh_ vs
scm_) seems patently bogus to me.

there should be multiple API's in Guile, but they should be more
well-defined, like:

1. R5RS as a collection C functions, that assumes a stack-scanning GC.

this can be defined with no other Guile-specific assumptions.

2. an API for registering your own primitive functions, that assumes
a stack-scanning GC.

this can be reasonably implementation-agnostic too (and is, in fact).

3. an API for providing your own Scheme types.

there's no way this can be done in implementation-agnostic manner.

4. an API for evaluator extension.

I think we need it (witness Goops).  the only way to do it currently is
to futz in eval.c.  I think we could do better than that.  this is also
absolutely Guile-specific, of course.

--mike

-- 
I'm on a seafood diet -- I see food and I eat it.           -- anonymous