Yes, you can do all those stuff in existing primitives. But maybe a little convenience macros will help, like auto-prefixing macros. And another thin macro that expands to 'with', with some bookkeeping features such as specifying the prefix in one place? Then let's call that macro 'module' and voila! You have modules.
Really, it is possible to build module system if you have enough primitives (what's 'enough' depends on what model you use). The point of modules is not whether it is possible or not. The point is that whether everybody agrees on a certain convention or not.
I originally considered writing a macro that did just that, and even called it module, but then I realised I was packing a load of disparate features into one macro just so it would look like modules in other languages.
I don't think the point is conventions (at least not yet). I think the point is that modules may be an onion, and we don't want any onions.
If the module system is an onion, it is an onion with a kernel, which is really a convention.
For example, see SLIB, the portable Scheme library http://www-swiss.ai.mit.edu/~jaffer/SLIB.html . It is designed to work with R5RS Scheme and before, thus it can't use any module systems. Instead, it uses a naming convention, which works pretty well. The problem is that, to make it work, all programmer should agree and follow the convention. The so-called module systems make it easier to follow the rules by making the existence of the convention invisible (automatically adding prefixes effectively, e.g.) or preventing programmers from doing things differently.
In the discussion of R6RS Scheme, where a module system is finally adopted, some people argued that you can roll your own modules system out of given primitives, and it had proven in the production code. But if you use your own module system (or convention) and I use my own, it will be difficult to mix two libraries. Whatever it is, we have to agree on one way. I think that's really the point.
I agree that module systems are conventions. What I don't agree with is that we should uncritically adopt them in Arc. There may be a better way. What that is, I don't know.
Then the important question is this: When you say better, better in what sense? Beyond a certain point, people have different criteria and your better and my better start to diverge.
In Scheme, traditionally such matter has been settled by "agreed to disagree"---instead of choosing one, the spec just leave it unspecified. But R6RS had a goal to allow portable libraries, so it had to choose one; for modules, it is better to have lesser but one module system, rather than having multiple ("better" in various regards) or than having none.
In Arc, ultimately it's up to pg.
[Edit: To be more PC, R6RS module is 'less agreed'. I do understand it is better in its design criteria.]
Good question. I'm sort of inspired by PG's thoughts about object-oriented programming, that it would be better if they offered the features a la carte rather that packaging them up into objects.
