|PG, as you said, ac.scm defines the axioms (things that cannot be defined in arc itself) while arc.arc defines the core of the language (anything that could be useful in any program and can be built from the axioms). Thus the language is, as much as possible, its own specification.|
As a consequence, I guess you want as few things in the axioms as possible. Therefore I don't understand why functions like +, < or > belong to the axioms, at least the way they are currently written. These functions are not simply imported from scheme as, say, - or /, they are somewhat redefined to be polymorphic (thus + will work with numbers, strings, lists, ...).
Wouldn't it be better to have these polymorphic definitions in the core rather than in the axioms ? That would imply, e.g. exporting + as num+, string-append as str+ and list-append as lst+, then defining + in arc.arc as a polymorphic call "routing" to these axioms, instead of just exporting your own opaque home-made +.
The main benefit of this would be :
1- arc would be even more written in arc
2- it would be possible to have an "à la carte" +, meaning that you could let more types be added with + (or remove those you don't want). If I understood well, that's one of the main goals of Arc ?
The same is, of course, true of <, >, len and probably others.
So, my question is : why did you do so ? Is it for performance ? Is it because you want to export as little as possible from the underlying implementation, the less axioms the better, even if these axioms are big black boxes ? Is it only temporary ?