Arc Forumnew | comments | leaders | submitlogin
A fast and portable interpreter for Arc
4 points by segoe 5611 days ago | 3 comments
Would you be interested in it? Outline of the approach:

Start with this code, written by Marc Feeley: http://www.ccs.neu.edu/home/will/Twobit/src/scheme.scm

It's a fast interpreter for Scheme written in (R4RS) Scheme, It's based on the notion of generating code as closures while passing the runtime environment around.

Because it's R4RS i can run it on Larceny and Ikarus. Tweaking it a bit and trying fib(30) on a repl on Larceny (windows xp), gives about three times the speed of the current mzscheme based Arc3 distribution.

The point...

- It would be portable accross any R4RS implementation of Scheme. I.E: if larceny changes anything, you can move on top of any other compliant fast scheme.

- It can be made more efficient (by doing some analysis before generating code for example)

- It's easy to modify it, and you can make it interact with the R6RS libraries Larceny provides too. (as well as others, like GTK)

- It supports both continuations and tail recursion if the underlying scheme supports them. (which larceny does)

I think the Marc Feeley's implementation is rather elegant, there is a paper about it here: http://iv.tu-berlin.de/TechnBerichte/2006/2006-02.pdf

So more or less that's it. I'll probably hack on it anyway just for fun but would you be interested on using it? is there a better approach?

Fun note:

It would be portable except it wouldn't work on PLT Scheme, because of inmutable pairs. (isn't that irony?)



2 points by rntz 5611 days ago | link

I'm unsure of whether this would in the end be any more portable than a compilation-based approach. The only fundamental dependencies arc has on plt scheme are on some of its library functions; AFAICT, arc compiles down to fairly portable scheme otherwise. So IMO the best way to make arc portable would be to a) write an arc compiler in arc, b) explicitly separate out the library functions arc needs beyond core r5rs, and c) for each scheme dialect we want to port to, write a support library supplying this functionality.

That's assuming we even want to keep Scheme as the backend, though I don't have any better suggestion. (Well, not yet...)

> It would be portable except it wouldn't work on PLT Scheme, because of inmutable pairs. (isn't that irony?)

Well, arc itself now contains hacked-in mutability for plt's supposedly immutable conses, so that portability problem is fixed :).

-----

2 points by jcw 5609 days ago | link

I clicked thinking you'd already written a fast and portable interpreter.

-----

2 points by segoe 5609 days ago | link

I didn't want to start before gathering some opinions on it :-)

-----