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
pgpDG40qvSwNE.pgp
Description: PGP signature
|
