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.

I'd kinda like to see Arc grow some sort of module system - even a very simple dictionary-based system like Python's or JavaScript can go a long way towards making larger programs tractable. Come to think of it, I think you could emulate JavaScript's system with closures and hashtables. Just wrap every module in a closure, which binds a hashtable to the module name and inserts each function into the hash table:

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
are).

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:

(module::function args)

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).

In JavaScript they're the same thing - objects do quintuple-duty as hashtables, records, objects, classes, and modules. Arc is very similar to JavaScript in terms of the primitive data types available - they're both Scheme-derived languages.

The reason I'd term call this modules is that they don't have the implicit-receiver that classes/objects do, nor do they have constructors. Once you define a module, that's it, and they live in the global namespace. You could change things around pretty easily so that instead of immediately executing the closure containing the module's namespace, you define it as a constructor function. And you could probably then come up with some macro to expand to a message send, which passes the object as the first argument to any method defined in it. I think you'd be stuck with explicit-self though, like in JavaScript or Python, instead of the implicit `this` of Java.