This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Guile API's (Re: About modules)
Well, in some sense Guile is also a compiler. Although
it doesn't translate into linear byte code it compiles into
a tree code structure. Once compiled ("memoized") there's
no way back -- well, there is, but that's a different story.
What concerns me is the evaluator itself. I think it would be more
maintainable if *every* type would know how to evaluate itself.
Actually we have a number of "hard coded" types which the evaluator
knows + an extension mechanism which allows us to "plug in" new types
(the SMOB Interface). I think that the smob interface is on a too
high level; one needs the possibility to quickly "plug in" a new type.
Per Bothner <per@bothner.com> writes:
> No. Kawa is compiler-based. The first thing is does with a Scheme
> <expression> is to translate it to a Java Expression type. This stage
> does macro expansion, and handles lexical scoping. For example (if
> ...) and (cond ...) are both translated to instances of IfExp, which
> inherits from Expression. Every Expression class has an eval method
> that evaluates itself. However, evaluating an expresion is only supported
> for "simple" expressions, such as procedure application; others signal
> an error. More complex Expressions are handled by the compiler, for
> consistency. So the real truth is that all Expressions know how to
> compile themselves into sequences of Java bytecode instructions.
>
> See the first paper mentioned at http://sourceware.cygnus.com/kawa/papers/ .
> It is slightly out of date, mainly in how procedures are
> represented, and doesn't mention some newer features, but gives a
> decent overview of how Kawa works.
> --
> --Per Bothner
> per@bothner.com http://www.bothner.com/~per/
>