Fwd: Mapping E to Kawa
Mark S. Miller
Mon, 01 Nov 1999 12:49:02 -0800
>X-Received: 1 Nov 1999 19:27:11 GMT
>To: "Mark S. Miller" <email@example.com>
>Cc: "Paul Snively" <firstname.lastname@example.org>, email@example.com
>Subject: Mapping E to Kawa
>From: Per Bothner <firstname.lastname@example.org>
>Date: 01 Nov 1999 11:23:33 -0800
>User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2(beta14)
>[Feel free to forward this as appropriate.]
>I've skimmed through the elangmanual.pdf, and I don't see any
>fundamental problems. Some comments:
>For an overview of how Kawa "works", I recommend the paper "Kawa:
>Compiling Scheme to Java". It is available at:
>It's a year old, but it still gives a good overview of
>At a very high-level, there is a language "front-end"
>that maps the source language into Expression trees.
>The front-end takes care of resolving lexical bindings
>to their defining Declarations. It also (for Scheme)
>handles macro expansion. Once you have the Expression
>tree with lexical names bound, then the rest of the
>optimizations and code generation is in theory indendent
>of Scheme. There are probably a few dependencies here
>and there, but I've been working on gradually eliminating them;
>A example ossible dependency is the handling of booleans: In Scheme,
>truth (in an `if' for example) is any value except for
>java.lang.Boolean.FALSE. If E boolean expression can be only true and
>false, this should be easy to handle, as long as true and false are
>java.lang.Boolean.TRUE and java.lang.Boolean.FALSE respectively.
>Kawa treats procedure values similarly to E - as a class
>with a distingushed method(s). However, in Kawa all
>functions are sub-classes of Procedure, and implement
>one or more of the "apply*" methods. See
>Of course, there is no requirement that E values map into their
>"corresponding" Scheme types. Thus for an initial port, you might
>not want to try to map E procedures into Kawa Procedure values,
>and instead just you the lower-level PrimProcedure values
>(which basically are Java methods). Still, if you can,
>using Kawa/Scheme types would be nice.
>Perhaps the biggest feature of the E kernel not readily
>supported by Kawa is patterns. However, there is no
>particular reason that should be considered a "kernel"
>feature. Even if it is, expanding patterns can be handled
>by the "front-end", which just needs to generate Expressions
>that bind values to the bounds Declarations. Thus the
>language-independent parts of Kawa do not need to know about
>patterns at all.
>Actually, I have been thinking about more general support
>for patterns, but I'm thinking about something much more
>general: Something that can be used for regex matching,
>for s-expression re-writing, for XML transformation, for
>"tuplespace" (a la Linda or JavaSpaces) matching, and even
>matching agains SQL tuples (a la query-by-example).
>Unfortunately, I haven't gotten very far with this yet.
> --Per Bothner