| PG seems to be opposed to building macro hygiene and namespaces into the language. If we assume there are good reasons for this (although I'm not too sure in the case of macro hygiene; see other comments defending the power of hygienic macros), would there be good ways of coping with the possible problems you get by not "restricting" the language with namespaces and macro hygiene? My thinking is that there are some commonalities between: 1) unintended symbol clashes when bringing in code from "elsewhere" into the single namespace 2) unintended symbol shadowing when expanding unhygienic macros In both these cases, the potential problem arises when assigning a value to a symbol (with =). What about giving the programmer increased control over symbol tables (they could be exposed as hashtables) at both read-time, macroexpansion-time, compile-time and even runtime, in order to have options for fine-grained control of symbol assignment? Examples: - When importing an Arc source file into the Arc image, you should have both the symbol table for the image (before importing) and the symbol table created by compiling the code to be imported available _before_ those symbol tables are merged, so you can use tools for comparing such tables for possible conflicts, and then merging them in a programmer-controlled way. - Likewise, when the compiler expands a macro where you think there should be no symbol shadowing, the programmer should have access to the symbol table that would result from the macroexpansion, and the symbol table that exists before the macro-expansion is done. (A common symbol table manipulation library could also be useful for increased control over the lexical scope of expressions or even continuations.) | 
