So can you use this to actually generate executables from Arc code (or do you have some other definition of standalone), and do you need the .NET framework installed to run those executables? What compiler do I need for MBase itself? C#?
What license does MBase come with? Is it open source? (If not, is it guaranteed to always be free?)
Does this work with Mono? (And Linux?)
And where is the download link for MBase itself? I managed to get to the download for MBase-0.3-generic.zip by using links to old versions and changing the version number, but there wasn't any link leading there. And the readme mentioned a msi distribution, but I couldn't find that either.
I managed to get the MBase pseudoArc compiler running on my Windows machine. So that means I can answer most of my own questions now... but I am still wondering about Linux/Mono support and licensing.
The compiler only supports a fairly small subset of Arc, so it isn't really usable on its own yet. But I am impressed with what I've seen of its performance, which I tested briefly using the factorial example from http://arclanguage.org/item?id=2455 .
Raw arc2: 27 seconds
Anarki: 25 seconds
Python: about 6 seconds
Mzscheme: about 1 second
Compiled MBase Arc: about 1 second
Dang.
If this compiler gets continued support and actually begins to implement most of Arc, it could really go somewhere.
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?
This sample compiler generates .NET executables (DLLs and EXEs), but it is potentially retargetable, more backends will be provided later.
To run these binaries you will need either M$ .NET framework or Mono (versions from 1.4.x are ok, not sure about older ones). MBase is free and comes currently as a binary only distribution (no compiler is required). It will always be free, core parts may be open sourced (most likely under QPL) when the code cleanup is complete.
Techpreview page contains link to MBase-0.3-generic.zip, I'll try to highlight the link better, thank you for pointing to this issue.
MSI distributions normally comes in a week after the generic zip bundle.
