Patrick Wright wrote:
> I'd like to hear (on this list) sometime how you approach
> interpretation vs. compilation in Kawa. No hurry (I imagine you're
> pretty busy ATM with J1 preparations and JFX), but would be
> interesting to see how you approached it, esp. since many languages
> we're hearing about on this list support an interpreted mode, or a
> compiled mode, and others support both. In that regard, understanding
> how you used your bytecode generation libraries in the interpreter and
> compiler would be interesting as well.
Quick summary:
The basic unit of compilation is a "module", which is typically
a source file, but it can also be a single expression (for eval),
or line (for the read-eval-print loop). A language-specific
parser converts the source code in a language-independent AST using
a hierarchy of Expression objects, with ModuleExp at the top. Primitive
operations are parsed into calls to builtin functions,
as are various "control structures", which are represented
as function calls, some of whose parameters are lambda expressions.
Name resolution is done by language-dependent code, but there are
some helper classes that can be used.
A couple of tree-walking passes do some analysis, type propagation,
closure analysis, and optimization. Some builtin or predefined
functions have special hooks to support custom re-writing ("inlining")
and type propagation.
Finally, the code generator walks the trees to produce executable
bytecode. Again, builtin function may have hooks to generate custom
bytecode. In "eval" mode, the codecode can be immediately loaded
(using a special ArrayClassLoader). Otherwise it is written to
a .class file, or an archive.
There are compiler options to generate an Applet or a Servlet.
With the latter, the module expression is evaluated to yield
a result, which then becomes the servlet's response.
Kawa can (optionally) support full tail-calls, with reasonable
efficiency, but there is some performance cost, and that mode
hasn't been tuned as well as I'd like. Kawa doesn't support
full continuations; it's something I've been wanting to do
for years, but it never had high enough priority.
Kawa is unique in supporting multiple languages, while still
having performance close to Java. One reason for this flexibility
is the above-mentioned hooks for builtin functions, which makes
it practical to generate excellent code for language-specific
features without modifying the Expression hierarchy. (The
separation between language-independent code and language-specific
code is fairly clean, though there are still a few rough spots.)
The low-level gnu.bytecode library is similar to BCEL and ASM,
but it is (I believe) better for code-generation (though less
suited for bytecode analysis/modification). This is completely
standalone and can be used without anything else from Kawa.
The higher-level gnu.expr package manages Expressions and
actual compilation. It is mostly self-contained, but it is not
yet as cleanly usable standalone as gnu.bytecode. However,
implementing a new language based on Kawa should be quite feasible
as long you don't mind just linking with the kawa .jar file,
and can deal with that the gnu.expr APIs may occasionally change.
(If you do, it's good to keep me informed so I can warn if/when
internal APIs change.)
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
