> This could be implemeted by sharing structure of the closure-alist in ac.scm.
Um. There's no such thing.
The arc-on-mzscheme implementation uses mzscheme functions for its own functions. What I mean is, something like this:
(fn (x) x)
is exactly the same as mzscheme's:
(lambda (x) x)
This is still not trivially implementable in mzscheme except by some serious mangling around (i.e. basically each Arc function becomes an object with a "lock" function which assigns free variables to specific values. By default when we execute this function we specifically lock the free variables to the global variables).
And true first-class macros will still remain very difficult.
You might be interested in my discussions with shader about how true first-class macros make it very hard to write efficient interpreters, must less even lousy compilers. http://arclanguage.com/item?id=8015
It's possible, but very difficult, and in general most implementeers will not find it worth their while to implement first-class macros.
Of course you are free to design and implement any language you want, and I know you've probably been the main contributor.
But I think the original spirit of Arc was to design a simpler language even if it couldn't be implemented as efficiently:
(Quoting pg, The Hundred-Year Language):
There's good waste, and bad waste. I'm interested in good waste-- the kind where, by spending more, we can get simpler designs. How will we take advantage of the opportunities to waste cycles that we'll get from new, faster hardware?
Of course not. Conceptually, Arc-F is just as clean as Arc. You can implement CLOS-style monomethods in Arc-F from the Arc-F side. You can implement the '+, '-, '* and '/ operators on the Arc-F side (you just need to provide the basic '<base>+ etc. operators on the underlying base system side). And I'm willing to bet most of you would never have imagined that not all functions in Arc-F are functions (some of them are special objects that are interpreted by Scheme) if I never told you about that.
Arc-F divides itself into the "IDEAL" and the "REAL". The "IDEAL" is how the language would be implemented in terms of the most basic axiomatic operators. "REAL" is how it has to be implemented to prevent it from being 10x slower than Anarki (yes, I actually did the IDEAL part first, and only later ported to the REAL part where bits of it are in scheme. We're talking 12 second load times for arc.arc, and arc.arc only).
Even PG himself abandoned the purely axiomatic approach when he found that performance was very, very bad. My aim is to return to a purely axiomatic approach in the IDEAL and to make appropriate hooks for the REAL part to optimize everything. As at is, Arc-F is about 2x-3x slower than Anarki. For me, that's acceptable. And so far, most of the speed loss is from function calls.
As a concrete example: in Arc-F, it's possible to overload '+ by simply overloading <base>+. If you have a new type foo and want to define how to add two foos together, you just overload <base>+. The neat thing is that this won't slow down arithmetic very much, if at all; if you were to write the equivalent overload '+ in Anarki (Anarki doesn't have the <base>+ hook, after all), arithmetic performance suddenly drops precipitously.
Also, overloading <base>+ is simpler: <base>+ only requires that you consider the case of adding two objects. + determines how to handle things when you do (+ foo1 foo2 foo3 foo4), specifically it converts the call to (<base>+ (<base>+ (<base>+ foo1 foo2) foo3) foo4)
So yes: my position is, by focusing on efficiency in implementation, it frees us to actually use the axiomatic approach without throwing in the towel and going non-axiomatic.
I like the REAL/IDEAL distinction. Always following the IDEAL path to make the "one hundred year language" without considering performance easily leads to unacceptable performance. Your experience with 'load clearly shows that.
