I replied in a comment on my post, but Disqus is having issues today and anyway I want to say a bit more. >> What should the expander do when it sees: quu

I replied in a comment on my post, but Disqus is having issues today and anyway I want to say a bit more. >> What should the expander do when it sees: quux (mumble, flarg) [1, 2, 3] { foo: 3 } grunch /wibble/i > It expands it. The expander should not see a stream of characters, as you show in that example, it should see a tree. This is the point: what tree? How many arguments does `quux` have? The answer isn't obvious, because `quux` isn't surrounded by any pair of delimiters. The net result: there isn't a clear way to write a JavaScript "lexer" that produces trees---i.e., a reader. JavaScript's syntax was not designed with this in mind, so there isn't a clear tree structure inherent in the syntax. (And even if you solve that problem, there are aspects of the JS syntax that depend on knowing the parsing context, such as whether grunch /wibble/i lexes as an identifier followed by a regexp literal or identifier-slash-identifier-slash-identifier. So the number of sub-nodes is not even clear until you expand enough to know what context that fragment appears in.) These are all issues you'd have to sort out to figure out how to make JS amenable to macros. But what it amounts to is figuring out how to design a reader for JS. Or at least, if you wanted to design a Lisp-like macro system for JS, you would. The point is, the fact that Lisp macros operate on trees (though syntactic trees, not "semantic" trees as you claim---that's a debate for another day) is directly enabled by being able to generate a tree rather than a stream of tokens from the reader. And that's only possible because the syntax was designed to support that. There's of course not just a single unique syntax that has this property, but Lispy languages have syntaxes that are designed to support a reader, and that's at the heart of what makes the Lisp approach to macros work.