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.
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.
If you did this for all local variables, and then used namespace-undefine-variable! to delete any defs that had been evaluated, I think you would get a fairly well restricted eval.
I agree with you - I think this is roughly the right idea, I just hadn't found namespace-undefine-variable! when I asked this question.
I think there's still somewhat of a problem with wrapping variables in a "let" with their deep copies - that prevents internal code from wrapping builtins and having other builtins use the wrap, because the let will make the builtin-wrap scope different from the outer scope. But you can do the special-suffix thing in this case.
Maybe I missed the point of your post, but if you just want temporary variables inside a block of code, can't you just use let?
(let var val
; use var
)
; now var is gone
Or use with if you want to declare mutliple variables.
This works if what you want is temporary local variables. (And it's better than tempset because it uses the stack to restore previous values of variables, and can create nested scopes.)
If on the other hand you are talking about creation of temporary global variables, then you might need something a little fancier.
Or perhaps you are talking about something like unintern from CL? I admit it might be kind of nice to have explicit intern and unintern primitives. But that is more of a namespace issue than merely an unsetting a variable.
cl-cont is a library that implements closures and runs on many CL implementations. So it's not a matter of CL can't do it, CL just has to use a library to do it.
I think there are conceptual problems mixing unwind-protect-like constructs and call/cc.
The cl-cont lib appears to only support a subset of CL (in particular unwind-protect is not supported).
So cl-cont doesn't demonstrate that CL can support it, only that a restricted subset of CL can.
I don't know if it is possible to sensibly accommodate unwind-protect and call/cc in the same language, it seems smarter people than I have avoided doing so.
Scheme's dynamic-wind serves the same purpose as unwind-protect (except with entry conditions as well, since a continuation could suddenly return into your protected code), and plays nicely with continuations. I'm not sure about the details, though.
Thanks for that, pretty interesting. I guess that makes writing entry and exit conditions a little more interesting, since they could end up being invoked multiple times.
Cool. pg, if you are reading this plz let me know if we should advertise to Arcers or if your group will be doing so. You would get more student projects allocated as an Arc-specific mentoring organization, btw. Lisp-NYC only got a few projects from Google last time, and Arc students would be competing against students for other Lisps for the allocation.
In the meantime, interested Arcers who qualify under the Google rules are free to conjure up projects they think will be attractive to whichever group ends up mentoring Arcers, and/or watching the Lisp NYC space for project ideas provided by us and/or mentors outside our group. In the end the student applies to Google who forwards to the right group for assessment which the group returns to Google who then finally decides. Hope that's clear. :)
