Re: Compiling Scheme to JVM bytecode

On Mon, Jun 14, 2004 at 06:07:11PM +0100, Tony Garnock-Jones wrote:
> Hi all.
> 
> I've been working on a simple Scheme compiler for a while now. Until
> recently I was targeting .NET, but I'm now switching over to the
> JVM. I've been thinking about how I might integrate the compiled code
> with SISC, to take advantage of the more-or-less complete runtime and
> make use of parts of the design (such as serialisation).

Interesting.  

> 
> This is close to being, but not quite the same as, the calling
> convention used in SISC at the moment. The simplest means of
> integrating the two evaluation styles could be:
> 
>     - extend class Value with
>       public void apply_compiled(Value[] args, Interpreter r)
>       which expects a continuation as args[0].

I'm not sure the above makes much sense to me.

> 
>     - implement some class CompiledProcedure extends Procedure, with
>       an apply(Interpreter) method similar to Trampoline.call above,
>       setting things up for a call to apply_compiled, except instead
>       of putting in a new ToplevelContinuation, the current
>       continuation from the Interpreter would be capture()d and passed
>       along.

This is my favorite option.  It is the least invasive to the rest of the 
SISC runtime, and makes the most sense conceptually, as SISC is still 
invoking a procedure.

> 
> This way, calls back and forth between compiled and interpreted
> procedures is reasonably transparent, and continuation capture Just
> Works for both halves.

What would calls from the compiled side to the Scheme side look like, 
and how would continuations created in a compiled procedure look to an 
interpreted one?  My guess is that the continuation would need to be 
invokable as a CompiledProcedure somehow.

Secondly, how would TCO be preserved.  Every call into a compiled 
procedure would presumably add control context.  Would calls out of the 
compiled procedure to an interpreted one do the same?  If one or the 
other is unable to break the cycle it could prevent general TCO.  Also, 
does your compiler support general TCO or some more limited form (like 
in a compilation unit for example?)

> 
> I'd appreciate feedback on this general outline. Am I missing anything
> important? Is there any way this design could be improved upon?

I'm a bit curious if the SISC main loop couldn't be harnessed somehow to 
do the trampolining.  That is essentially its only job at the moment 
anyway.  I'm also very interested in seeing an example procedure (maybe 
even/odd) compiled.  I can guess at what it would look like, but it'd be 
interesting to see nonetheless.  And how are datatypes handled?  

I seem to have fewer answers than questions. :)

	Scott

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAzj+Ur9IW4v3mHtQRAme3AJ9M9EKeJtC1OUqdiMOqgTg37Vln1wCgjezJ
zIKLXDlLHrnDG2m7U0E8UM8=
=G4jo
-----END PGP SIGNATURE-----