Mono is supported (in fact it is the main development platform), as well as mono-xsp2 as web backend (did not tested it with IIS yet).
And, yes, I am hoping to support pseudoArc. Such an early release was done to attract a community feedback and to raise a discussion around the minimalistic core language properties. pseudoArc is public domain - no license restrictions, so everybody can extend it. The best way would be to keep the core very simple and provide the rest of Arc functionality as a separate library.
Yes, I think a minimalist approach definitely fits the Arc design. If you can make the axioms compatible with those provided in the standard ac.scm, you can guarantee the compatibility of code built on top of that.
Now that I have had a little more time to play around with the pseudoArc compiler, I realize exactly how small a subset of the core has been implemented so far. (I mean, seriously, read is not a convenience.) I would definitely like to see a more full-featured implementation develop. (But seeing as I am not at all familiar with your MBase system, I don't think I would be of much help.)
Unfortunately, compatible axioms don't guarantee compatible code on top. The big problem is the operations that use "system" (e.g. date and ensure-dir) break on different OS's. This is the root of many of the Windows problems.
For this reason, I believe that use of "system" makes a mockery of the axiomatic construction, and has no place in the Arc core.
But at the very least, if both standard Arc and offshoot implementations both use system, they'll both break in the same way. Therefore code will still be "compatible" across Arc implementations (in that it will generate the same error messages on all implementations).
Yeah, I know that doesn't fix the problems you mentioned, and yes, I run Windows so I do encounter those problems with the vanilla Arc releases. But we can't expect a offshoot implementation to do anything about the problem, we really need pg to solve the problem at the source.
While Unix did win, that doesn't mean that Unix's names won. It's Unix's features that won. So it's reasonable to provide certain operations, but implementing them in terms of (system "unix-command-name ...") is not.
Of course, I use Mac OS X, so it's not like I'm adversely impacted. But the point still stands.
Yes, the subset is really small (and, I admit, not yet sufficient for a metacircular bootstrap). The whole idea is to provide basic .NET reflection functionality and implement all the rest in Arc itself (exactly as MBase itself is unrolled from the very minimalistic core).
But, some fundamental Arc features are not compatible with this core at all: zap (needs a strange memory model, not quite possible to implement efficiently in .NET, and, any way, is too non-functional) and mutable strings (that is easy to fix, if someone really needs mutable strings, I am not quite convienced). Also, numerical tower must be implemented in the core compiler (at least a parser must recognise all the variations and compiler backend must emit all the literals correctly), but it does not seem to be strictly specified for an original Arc so far.
Next release (to be available soon) will contain more of the basic functionality and a consistent .NET bindings framework. This must be enough to grow the language from the core.
What we really need is a formal definition for Arc operational and denotational semantics.
I'm interested in your comment that zap doesn't fit well. zap is built on top of setforms and assignment, so if zap doesn't work, then there are probably deeper problems. Do scar, scdr, sref work?
