Just curious. Most of what PG has written has been about CL, not Scheme, so I'd have thought that CL would be the natural choice for an Arc implementation. An Arc built on, say, SBCL would have the advantage of being faster than one built on MzScheme (related to my previous post arclanguage.org/item?id=4579).
I would say the first implementation is in MzScheme for two reasons, both related to the design of scheme and the stated goals of Arc.
First, Scheme was designed to be a very pure dialect of Lisp. In other words, it is trying to be a minimalist language with only what is absolutely needed in the language itself. Until only recently (i.e., before the ratification of R6RS) the language specification for Scheme was around 30+ pages whereas the spec for CL numbered several hundred pages (I believe over 500 pages at least). One of PG's stated goals was to create a language built on axioms, thus he wants a very simple language very akin to the ideas behind Scheme.
The second reason, as I see it, is that Scheme supports continuations natively which makes certain types of applications (i.e., web applications) very easy to write--its no wonder that the main examples given to date have been web based applications all using continuations to share state between rendered pages.
Finally, as for why MzScheme, well, its well supported, very portable, speedy, has plenty of available libraries (using a CPAN-esque system), and overall its probably the best Scheme dialect available. (Please, no flaming here, I know others may be better in certain areas, but overall, MzScheme probably has the greatest combination of advantages and the lowest barrier to entry of all the Scheme implementations out there.)
Granted, this was referring to a different Scheme's implementation, but I think the basics hold. Not that it's a specific "why", but it would appear that several different implementations of Arc have been tried and the MzScheme one stuck for reasons being explored in this thread.
I suspect that using a clean, minimalistic language basis felt right for building a new language. And PLT is well ported all over the place.
But actually, I predict that we'll eventually start to see lots of arc implementations riding on top of lots of different Lisp implementations: sbcl, but also gcl, guile, chicken, maybe abcl, sisc . . . And that sounds cool to me!
I hope that arc keeps a canonical and authoritative implementation. One of the big problems keeping many people from deploying Lisp applications is the uncertainty and difficulty in choosing a particular implementation. It can also end up fragmenting developer time and you will inevitably end up with incompatible but extremely similar arc implementations everywhere.
One or two canonical implementations is fine, but there should be one authority for the language and it should be a fairly good implementation.
I think the axiomatic approach is intended to stop this. Lisp suffered because the spec was complex and ambiguous. To port Arc, just port the axioms, run the "spec" et voilà, you have a conforming implementation.
It should be noted that pg intends to implement more of Arc in Arc, when he gets the time.
In fact I have an implementation in SBCL half way (it basically can load arc.arc, but I haven't bothered with network/thread functions yet). To solve the call/cc problem I got to the point of doing a CPS transform, and since Arc has only 4 special forms (very few axioms, as you say) this was 'easy'...
It's not theoretically impossible that Arc could eventually be metacircular (by writing the Arc compiler in Arc). I think that would be even cooler than implementations in SBCL, etc. This would also maintain the authority of the canonical implementation.
