Arc Forumnew | comments | leaders | submitlogin
3 points by Metaprogrammer 5890 days ago | link | parent

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 5890 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 5890 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 5890 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?

-----