Arc Forumnew | comments | leaders | submitlogin
An alpha (buggy and slow) port of Arc to plt4
5 points by CatDancer 4537 days ago | 4 comments
A straight port of Arc from plt3 to plt4 would probably involve something like:

a) rewriting the Arc runtime to run in plt4

b) rewriting the Arc compiler to produce code that runs in plt4

c) rewriting the Arc compiler so it itself runs in plt4

This would be overwhelming to try to do all at once (at least it would be for me), so what intermediate steps could we find that would let us tackle this project a bite at a time?

The approach of this port, as a "phase one", is to write enough of an plt3 emulation library in plt4 to run Arc.

The disadvantage of such a plt3 library is a loss of efficiency: the plt4 runtime will construct an immutable list terminated with '(), the plt3 library converts that to a mutable list terminated with '(), and the Arc runtime converts that to a mutable list terminated with 'nil.

However, there are several of advantages to writing a plt3 library layer:

It allows us to use the released Arc compiler code (ac.scm) unchanged. So if any bugs show up, we know that they're in our plt3 library or in plt4, not in our messing around with the Arc compiler.

Being able to use the original ac.scm code naturally makes much easier to follow new releases of Arc. The plt3 library layer may need to be extended to support features of plt3 that the new release may happen to using, but we don't need to be merging changes to the Arc compiler in with our port of the compiler to plt4.

The plt3 library layer implements just enough of plt3 to run Arc, so it defines a minimum variant of Scheme needed to run the released Arc compiler. Someone who wanted to port Arc to a different language might find this a helpful stepping stone: implement enough of Scheme to work in the same way as the plt3 library layer does, and then the Arc compiler could be used with few or no changes.

Finally, a "phase two" port of Arc to plt4 might start modifying the Arc compiler so that it produces more efficient plt4 code instead of plt3 code that gets emulated. Having a working port of Arc running in plt4 would make this much easier: someone could take small steps by having the Arc compiler generate some small bit of plt4 code, see that it works, and then implement another small bit; instead of having to do a massive rewrite all at once.

This patch ( isn't a working "phase one" port yet, it's a buggy and slow alpha "0.01" initial version.

There's some bug in error reporting that show up when an error occurs while in a defop that complains that some continuation mark function isn't defined, I haven't looked into this yet.

There was some custodian function that I didn't find in plt4, for now I just have the custodian code commented out in the Arc compiler.

The port is largely untested, I expect there will be various things that will show up, such as perhaps some plt4 immutable lists that I'm not converting yet.

The r5rs emulation library in plt4 came the closest to implementing the parts of plt3 that Arc needs, so I used it as a base for my plt3 library. I hadn't quite figured out last night how to get the Arc compiler (ac.scm) implemented as a module imported into the namespace used by the r5rs eval, so this port currently "load"s the Arc compiler. The plt4 port is noticeably slower than running Arc in plt3; this may be because not using a module prevents normal PLT optimizations, the use of the r5rs library layer, or both.

Next steps for this "phase one" of the port, after fixing the immediate bugs, might be to regain implementing the Arc compiler in a PLT module, and / or implement parts of plt3 directly instead of using the r5rs library.

Because this port doesn't have ac.scm running in a module yet, Arc needs to be launched with the PLT "plt-r5rs" command, which also means there's no plt REPL running that we can ^C to.

  $ wget
  $ tar xf arc3.tar
  $ cd arc3
  $ wget -O - | patch
  $ ~/plt-4.1.5/bin/plt-r5rs as.scm
  Use (quit) to quit, (tl) to return here after an interrupt.

1 point by shader 4537 days ago | link

I understand that it should be slower with the double layer of conversion, but how much slower have you found it to be in practice?

Could you give us some comparisons? It would be great if we could use the latest version of scheme, even if it comes at a modest performance penalty. Arc isn't exactly designed with performance in mind as it is, so as long as it doesn't become unusable this could be quite helpful.


1 point by CatDancer 4537 days ago | link

Right now getting to the "arc>" prompt is 6.2 times slower, but that could be from not loading the Arc compiler as a module yet or from using the r5rs library.


1 point by CatDancer 4534 days ago | link

New patch available:

This update gets ac.scm back into being a module, so to run Arc using this patch go back to using "mzscheme" as the command to run:

  ~/plt-4.1.5/bin/mzscheme -f as.scm
but no "-m", as that option has changed in plt4.

Getting ac.scm back into a module makes this version almost twice as fast as the last version of the patch. Unfortunately that's still not very good: it's taking 3.5 times as long to get to the Arc REPL prompt with this patch using plt4 as it does with the unmodified Arc using plt3.


1 point by CatDancer 4535 days ago | link

There are some amusing moments that happen when I work on the porting project... here's the Arc compiler, running as normal in plt3:

  > (ac '(fn () 3) '())
  (lambda () 3)
and the Arc compiler running in a module where I forgot to import unquote and unquote-splicing:

  > (ac '(fn () 3) '())
  (lambda ,(let ((a (ac-denil args))) (if (eqv? a 'nil) '() a))
    ,@(ac-body* body (append (ac-arglist args) env)))
The fix (import unquote and unquote-splicing) was both obvious and simple once I figured it out, but in the meantime I was quite bemused: how did I manage to do that?! :-)