To answer your question, I would be stupid enough to do this because
PROS and CONS seem like reasonable variable names. I would (and have)
name variables first, tokens, blank, date, and many others for the
same reasons. We're not talking about redefining functions, just
lexical binding variables in a small scope.
In a Lisp 2 like Common Lisp it is very easy to work around name
collisions problems with a module system. It's much harder to solve
this problem in a Lisp 1 with just a module system. All the ways I
know how to solve the collision problem in a Lisp 1 that use namespace
management require integration with the macro expander. Is there a
better way? I'd love to hear it.
Now I see -- that's great, thanks. (It was the missing UNIQ that
got me, I can add parens :))
I think that if we kept going down this direction we would
eventually come up with a macro system that was "hygienic in
practice". Building a good and simple hygienic macro system is a
very achievable goal.
All I really want to say is that there isn't a trivial silver
bullet solution: A simple module system doesn't fix name
collision. A simple code walker doesn't fix it (it needs
integration with the environment.)
I eagerly await the version of Arc that has a macro system where
name collision can be avoided.
These are very hard to get right without hooks into the Lisp
environment (at least they are for me!). For example, we always
uniqify the variable names, but sometimes that doesn't do what we
On assertions: it would really be nice to have at least just one extra namespace for local variables, I suppose, with printnames that are the same as the global namespace. new-fn then translates from symbols in the global namespace (which is what read should always emit) to local variable namespace. Aw crick, it's a hard problem.
Also, current bug with this implementation: (fn (do) `(do ,do)) will fail, I'll need to analyze do. And stuff like (fn (b) (tag b (prn "foo"))).