ParrotVM

Makes my pants uncomfortable. Register based, tail call optimizing, supports call/cc(!), has the beginnings of JIT compilation… the GC isn’t exactly bleeding edge but at least isn’t one of the stop-the-world sorts (something about 3 color marks and a background thread doing incremental sweeping IIRC), and like the layout algorithms in xmonad it is easy to replace with something better when one comes around. Oh yeah, and threading. Decent looking FFI. The promise of calling libs from other languages in the future (like the way OCaml can talk to any Perl module from CPAN). And it reached 1.0 with a stable API recently. And interestingly there seems to be talks about working along side the LLVM folk…

There’s just a lot of cool shit going on here. Whereas Java/.Net are trying to bolt in the infrastructure to support dynamic languages, Parrot’s designed from the ground up to do this.

Perhaps GC wouldn’t matter much if something like newLISP with its funky one reference only “GC” were ported to it… on that note I should try to compile newLISP to LLVM bytecode.

And Java’s planning (apparently) on supporting TCO and if it already did, so would Clojure (the recur thing just drives me loopy, pun intended), and I probably never would have noticed Parrot.

For that matter, Clojure on Parrot would rock my balls too. And there’s word of Parrot eventually maybe understanding JVM/.Net bytecode… shouldn’t be much of a tweak from there…

You know? A few months ago I found myself wishing I had been born in the 60’s or 70’s, so I could have been around when all of the cool Lisp stuff was happening. I think I’ve changed my mind… this is a fucking awesome time to be here.

And as long as my ParrotVM post has turned into an obscure Lisp post, I should mention Arc. Arc is a Lisp. There, I mentioned it. Now let’s never speak of that again.

Who wants a non-toy R5RS Scheme on the Parrot VM?

So do I, go write me one. Here’s how (I hope):

pre-scheme is essentially a lispy-syntax C, complete with memory allocations, freeing, goto, minimal TCO, no GC… basically disgusting from a (this, anyway) lisper’s POV, and a far cry from the shear sexiness of R5.

The interesting thing about it though (other than making C a saner language) is that Scheme48’s VM is implemented via Scheme48’s pre-scheme->C translator, which as it happens, in true Lisp fashion, is itself implemented in Scheme. And I’d imagine implementing the minimalistic pre-scheme to be a far sight easier than implementing all of R5. You can look at the Scheme48 distribution’s makefile to see how to go about getting pre-scheme loaded to play with.

It may be a weird way to go about it, running a stack based VM atop a register based one (let alone one wanting malloc/free), but I’d think it to be the quickest route towards non-toy R5 on Parrot, and if nothing else a sufficient stop-gap until “native” implementations approach practical usability. Plus you already have most of your test suite for free.

Of course I havn’t looked into this in any depth, particularly what the Parrot implementation of pre-scheme would need to do other than parse the syntax. And I don’t really have the time to. So I thought I’d toss the idea out there and see if anyone else picks it up. What the hell, it’s worth a shot right?