Fwd: Mapping E to Kawa

Mark S. Miller markm@caplet.com
Mon, 01 Nov 1999 12:49:02 -0800


>Delivered-To: ricochet.net%markm@ricochet.net
>X-Received: 1 Nov 1999 19:27:11 GMT
>Sender: bothner@magnus.bothner.com
>To: "Mark S. Miller" <markm@caplet.com>
>Cc: "Paul Snively" <psnively@earthlink.net>, per@bothner.com
>Subject: Mapping E to Kawa
>From: Per Bothner <per@bothner.com>
>Date: 01 Nov 1999 11:23:33 -0800
>Lines: 58
>User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.2(beta14) 
>(Dionysos)
>
>[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:
>         http://sourceware.cygnus.com/kawa/papers/
>It's a year old, but it still gives a good overview of
>Kawa internals.
>
>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
>http://sourceware.cygnus.com/kawa/api/gnu/mapping/Procedure.html
>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
>per@bothner.com   http://www.bothner.com/~per/


         Cheers,
         --MarkM