Arc Forum | Arc compiler for .NET

Arc Forum new | comments | leaders | submit login

13 points by Metaprogrammer 6468 days ago | 15 comments

Hi all,

Here is an implementation of Arc-like compiler for .NET platform. It is relatively simple, and may contain some ideas that could be of interest to this community (e.g., a minimalistic intermediate core language, some compiler implementation techniques, etc.). The code is public domain, but it requires the latest MBase distribution to compile and run. Arc compiled code can be used standalone.

http://www.meta-alternative.net/techpreview.html

Your comments are welcome, please send them to info@meta-alternative.net

5 points by eds 6467 days ago | link

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.

-----

4 points by eds 6467 days ago | link

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.

-----

4 points by Metaprogrammer 6467 days ago | link

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.

-----

1 point by eds 6467 days ago | link

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.)

-----

6 points by kens1 6467 days ago | link

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.

-----

2 points by eds 6467 days ago | link

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.

-----

4 points by almkglor 6467 days ago | link

"Unix won" -- pg

http://www.paulgraham.com/arcll1.html

-----

7 points by absz 6467 days ago | link

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.

-----

1 point by Metaprogrammer 6467 days ago | link

Any effort towards a strict definition of this kind of functionality ends up with something like R6RS (which is IMHO overbloated).

-----

3 points by Metaprogrammer 6467 days ago | link

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.

-----

3 points by kens1 6467 days ago | link

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?

See my description of setforms for more info on how it's all put together: http://arcfn.com/doc/setforms.html

-----

3 points by Metaprogrammer 6467 days ago | link

An interesting point, I've missed that bit. If zap is built on top of setform, than it can be implemented with no performance drawbacks.

-----

1 point by Metaprogrammer 6467 days ago | link

Ok, got it, it is just the same good old notion of lvalues. An elegant solution, but with all the same restrictions.

Something like (= ((fn (x) (x 1)) str) #\A) should not work, right?

-----

5 points by Metaprogrammer 6467 days ago | link

Hi,

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.

-----

5 points by Metaprogrammer 6468 days ago | link

P.S. The exact URL is: http://www.meta-alternative.net/pseudoArc.zip

-----