[KazimirMajorinc]

I think Wand's result is straw man if used against fexprs - and Wand really didn't used it that way. Essentially, he says, with fexprs, there is no source => source transformation that can work in all contexts. Ok - but I am not interested in such transformations. Very few programmers are. Whole practical point of these transformations are that they can help to implementers to implement optimizing compilers.

But - if one wants source -> source transformation that works in ALL contexts, whatever the reason, he can limit his own use of fexprs - and hence, allow various degrees of such source transformations. For example, he can use fexprs under same limitation macros are used, and in that case, fexprs can be "compiled away" just like macros can. But - he can do it on his own, in some or all of his projects, or even only in some parts of the projects. There is no need to make collective decisions of that kind. Again, it is consistent with idea of Lisp, in which borderline between language designer and programmer is blurred, or at least, it was imagined that way initially.

Shutt has interesting and novel approach, and his approach is independent of the severity of overshadowing of the variables problem he addressed. And how severe is that problem? Not really. It is actually the same problem that exists with macros, and techniques used in CL or Scheme (gensyms, hygiene) for macros can work as well with fexprs.