> But, Haskell has no answer to LISP macros.

Lazy evaluation. Template Haskell. Quasiquotations (EDSLs). The GHC API. (Liskell.)

I believe between them anything Lisp macros can do they can do, though it may not be so easy. (Strangely, we seem to have little need of them, but I will leave it to the reader as to whether this is a Blub situation or regular Haskell is just that good.)

My theory, as someone admittedly inexpert in both Lisp and Haskell but having used both on occasion, is that both are so ridiculously powerful in different ways compared to "normal" languages that very few people ever even reach the point of being comfortable Blub programmers in either, never mind hitting the wall and wondering "what's next?" [0]

Really, how many programmers are out there who simultaneously 1) spend enough time with either language to master it 2) are smart enough to not only realize the language is limiting them, but to invent a new language to surpass those limits 3) aren't heavily tied to their current language 4) have enough spare time to bootstrap a new language with all the associated scaffolding (libraries, &c.) needed for anyone to want to try it?

[0] Feel free to substitute Scheme, an ML dialect, or other related languages into that sentence.

For something going beyond (but including) Haskell, see Curry [1]. Curry marries functional and logic programming, and compiles down to Haskell in recent versions.

[1] http://en.wikipedia.org/wiki/Curry_(programming_language)

The "may not be so easy" part is the trick.

But that's a tradeoff you make. If you have anything more than the most rudimentary of basic syntax, macros become hard. Whereas most of the things that Haskell brings to the table can be incorporated into any other functional language.