I totally agree that these things should be non-global. In my opinion the grain should be as fine as possible, so that you can use embedded DSLs whenever possible (like w/html or LINQ).
But it's worth pointing out that there are work-arounds to a global read table. In CL, for example:
Regarding the use of interfaces to specify the language version: have you ever considered making the language itself a package? The base language could just be a very primitive one, and then everything else could go in a package. It would mean there is no real distinction between 'the language' and 'a package that defines its own syntax'. That feels quite Lispy to me.
> Regarding the use of interfaces to specify the language version: have you ever considered making the language itself a package?
Uh, yes. That's how it's already done. That's why arc.arc is itself a package. In fact, when you say '(in-package foo), the only thing that the contexter will add to the newly-defined package foo are the Arc axioms: '<axiom>fn, '<axiom>if, '<axiom>quote etc. That's why you have to declare '(using <arc>v3) for each package - because otherwise the language doesn't actually import arc.arc
Edit: Ultimately (and this is another disagreement with PG) arc.arc is a library, not part of the language. It's like the libc in this respect. Because you see, we already had the 150-year language 50 years ago.
Edit2: as an aside, the package system even lets you export a binding for 'quote, 'quasiquote, etc. In fact, once we have defined a formal method to add ssyntaxes, it would be possible to add support for `(let foo# ,foo (something foo#)) in a library, not in the language. How? By defining an export for 'quasiquote, say (interface v1 <auto-uniq>quasiquote), where <auto-uniq>quasiquote is a macro that expands to <axiom>quasiquote
> In my opinion the grain should be as fine as possible, so that you can use embedded DSLs whenever possible (like w/html or LINQ).
Hehe. It's in the arc-f/ directory more for historical reasons than because it's not a library, and also because it's treated specially (it gets precompiled to Scheme bytecode, for example).
As an aside, arc-f currently handles loading by wrapping a sizeable bit of 'load in 'atomic, but this is unnecessary, I think, if I use a thread-local for current-load-file* and friends.
