Re: [Pika-dev] Re: Round IV: xl and all that (looking ahead, mostly)

[Tom Lord]

    > From: Andreas Rottmann <address@hidden>

    > Now that I have probably quite a few hacking cycles left over in
    > the next few weeks, I'd like to know how this xl stuff relates
    > to Pika and what should be done on the Pika side, given that I
    > want to spend some of those cycles on Pika hacking. AFAIR, the
    > thing that keeps us from a complete runtime is a few lacking
    > udstr pieces in hackerlab, and wrapping those up in libscm
    > (which I have in preperation to a certain extent, already). On
    > the eval part, I've no clear impression how this will work
    > out. Could you describe how xl, furth and Pika come together and
    > where one could help with this?

Yes, udstr is getting closer.

About eval...

The very general idea is to use a register machine, furth/gtgc
essentially.  We can start by intepreting a simple graph-code (ala SCM
but without so much tag hair) and go from there.

Such an interpreter _can_ be coded by hand but it can also be written
in xl pretty effectively.   The advantage of writing it in xl is that
while a trivial ->C translation gets you almost exactly the by-hand
graph-interpreter, the xl code is easier to optimize both by hand and
by better compilation ->C.

You could think of it this way:

A Scheme graph-interpreting VM resembles a little finite state machine
that, each cycle, transforms the contents of registers, possibly
side-effecting the store and the external environment.

XL is a little equation language that's nice for implementing finite
state machine rules.

Some things we want from the Scheme finite state machine are that it
run "stackless" (i.e., not use the C stack for recursion), that it be
multithreaded (allow "timesharing" between multiple runs of the state
machine), and that it be nicely interruptable.  Xl provides all that,
too.

They (pika and xl) should ultimately join up pretty seemlessly
although I don't have all of the details worked out yet.

-t