Arc Forumnew | comments | leaders | submitlogin
1 point by eds 4739 days ago | link | parent

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 4739 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 4739 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 4739 days ago | link

"Unix won" -- pg


7 points by absz 4738 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 4739 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 4739 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 4738 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:


3 points by Metaprogrammer 4738 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 4738 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?