| 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 (http://hacks.catdancer.ws/plt4-port.3.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 http://ycombinator.com/arc/arc3.tar
$ tar xf arc3.tar
$ cd arc3
$ wget -O - http://hacks.catdancer.ws/plt4-port.3.patch | patch
$ ~/plt-4.1.5/bin/plt-r5rs as.scm
Use (quit) to quit, (tl) to return here after an interrupt.
arc>
| 
