Oh, I disagree. It looks ok in toy examples (something that is true of many languages' macro facility) but all the calls to CONS and LIST and APPEND and whatever else you need quickly become unwieldy. They obscure the structure of the expression you're trying to build. This is exactly the problem that backquote-comma-splice (on top of s-exprs) solves. And I suppose we need to throw in single-quote too.

It's interesting, though, that this is a usability question rather than a technical one, i.e. you can build the same expressions without that notation, just not as easily. But that's what's great about that Whitehead piece I linked to: he shows how fundamental this is. It seems like a surface matter but isn't, because it influences what other things one can use one's limited mental capacity to do. It makes subsequent thoughts possible that wouldn't otherwise be. (Edit: this is why programmers who talk about how language doesn't matter are deeply wrong. And also why programming languages have surrounding cultures. But I go off topic again.)

By the way, your macro example is off, since there's nothing to cause X to be evaluated; it's forever embalmed in that outer QUOTE.

What's great about lisps that support modifications to the Reader is that you can go even beyond the standard sugar and use your own characters for some special purpose. (e.g. adding map-syntax with curly braces...)

> (It bugs me that I can't think of a simple example that must be a macro (and not a function), but you get the idea.)

My main three rules: 1) delayed, conditional, repeated, etc. evaluation of arguments 2) compile-time computation for massive optimization potential 3) running or inserting code before or after any of the argument forms (useful for tests--init clean env, run test body, destroy env) or changing the argument forms themselves.

> I can't think of a simple example that must be a macro (and not a function)

Implementing IF in terms of COND or vice-versa.