Hahahaha no. Lisp-1 + unhygienic macros + no module system = a world of pain when projects grow beyond a few thousand lines, even ignoring the lack of user-defined data types. The lack of structured data is less of a problem than it might seem, because you can write accessor functions that abstract away whether it's stored in a list or hashtable and the precise keys, and just use those. The issue is namespace-pollution from all those accessors.
As far as I can tell, having a purely closure-based module system won't actually
solve the lisp-1 redefinition problem; to use your module system, some manner of
compile-time token capture is necessary. Essentially, the problem is:
However, as you can imagine, this will get unwieldy fairly quickly (like you,
I've downloaded the arc0.tar file, but not actually bothered to downgrade my
copy of plt-372; i.e., I'm not sure how canonical the provided arc snippets
Of course the ignored caveat is this: so many bloggers are up in arms over this
point, it's presupposed that being able to change core library functions is a
defacto terrible thing--at work, where we have a massive C/C++ codebase running
on some unmaintained, sourceless, legacy APIs, being able to (for example)
add/fix methods in some of the base classes would be a significant time-saver.
I think Arc as-is makes it a bit too easy to shoot yourself in the foot;
however, I'm firmly in the camp that being able to update core functionality
should be allowable.
Also, for better or worse, look at emacs: a massive, mature system that contains
no module/namespace system, no closures, and, due to its dynamic scope, would
fail each of the above examples. I'm not saying I hope Arc emulates these (lack
of) features, however, it's still proof that they're not necessary for large,
real-world (whatever that means) projects.
The big problem is def and =s update a global symbol table. They are not like Scheme and define. If def obeyed local scoping rules and could be shadowed, the problem is shadowing has to be done explicitly. That is why this is painful and unwieldy. Ultimately, this needs to be fixed or Arc will be needlessly crippled.
What kind of syntax should we use to denote the module? Something like:
This idea comes from Ruby, though I am not sure it necessarily plays well with the function composition operator (func1:func2). I wouldn't want to use -> or "." because of the concept collisions those would create. Could we just use something that doesn't have a mainstream meaning, like (module#function) or (module>>function)?
module::function looks good to me. Someone else suggested allowing user-defined syntax characters; this would be a good use-case. It only has to expand into (module 'function), so the implementation is basically trivial.
Why not module:function? Abuse the property that : stands for composition. A more lispy solution of (module function) might also work, and its only an extra character. Though if I were going for an Arc solution, it should probably be (bin fn) or (md fn).