Does Clojure's single-namespace approach constrains you in any way when programming macros?

Question

In the article Technical Issues of Separation in Function Cells and Value Cells, Kent Pitman and Richard Gabriel explains the decision of making Common Lisp a Lisp-2:

There are two ways to look at the arguments regarding macros and namespaces. The first is that a single namespace is of fundamental importance, and therefore macros are problematic. The second is that macros are fundamental, and therefore a single namespace is problematic.

According to that, when programming macros, a single namespace in macro programming is inherently problematic.

But Clojure's approach is a little bit different: the backquote does namespace resolution.

In chapter 9 of the book On Lisp, Paul Graham talks about avoiding variable capture by separating code in packages:

However, packages do not provide a very general solution to the problem of capture. In the first place, macros are an integral part of some programs, and it would be inconvenient to have to separate them in their own package. Second, this approach offers no protection against capture by other code in the macros package.

As far as I can see, Clojure's solution to variable capture looks like the packaged option showed by Paul Graham.

One of the major drawbacks pointed by Paul Graham is that it would be inconvenient to separate macros in different packages, but Clojure's backquote does it automatically, by prepending the namespace of the symbol, right?

So, is it a complete solution to variable capture? Or Kent Pitman's words still apply? If there is any problem that Common Lisp's separeted namespaces can handle that Clojure cannot, could you write down an example?

Answer 1

I have never encountered a limitation with Clojure's macro system. It's a fully general macro system, and to my knowledge it is exactly comparable with Common Lisp in terms of fundamental capabilities.

There are obviously many syntactical differences, but I think they are mostly superficial and don't affect the expressive power that you can achieve with macros.

My view is that Clojure gets a lot of design aspects right here:

• Lisp-1 is simpler and conceptually clearer than Lisp-2, particularly in a functional language where you actually need to treat functions as first class values.
• Symbol capture generally isn't a problem - the Clojure syntax quote and namespace system do a good job of making macros both usable and readable.

As a final comment, the summary of the linked article is quite illuminating:

The bulk of arguments that focus on clean semantics and notational simplicity tend to favor uniting the function and value namespaces..... We feel that the time for such radical changes to Common Lisp passed, and it would be the job of future Lisp designers to take lessons from Common Lisp and Scheme to produce an improved Lisp.

In my humble view - Clojure is a good example of an "improved Lisp".