This is cool, but I think it's a necessity when using macros that the macro code itself be readable. Otherwise, it's very hard for someone else (or yourself later) to come along and figure out what the hell is going on. Although that runQ utility looked nice, its output, even when indented, is quite complex. Sure, I can figure it out, but I can't look at it and guess what it's going to do like, say, with quasi-quoting.<p>I mean, it might even be clearer-looking to output strings. Not saying that outputting string programs is good, but it is a good lower limit for how complex the code for your macro system can be in order for it to be useful.
I'm still a TH newbie, but i collected a couple of tricks for working with TH interactively in GHCi on my blog:<p><a href="http://coder.bsimmons.name/blog/2010/12/working-with-template-haskell-in-ghci/" rel="nofollow">http://coder.bsimmons.name/blog/2010/12/working-with-templat...</a>
I love TH (though not as much as metalua and metaocaml), but I've never had the occasion to use it. I've used a library that uses TH to parse out my prop_foo into a main method that will run all the quickcheck tests, but that's about it.<p>Is there any particularly well-done TH being used somewhere in the real world? (You don't have to show me the code, just what problem you had that TH solved.)
"Haskell too has macros. The subsystem is called Template Haskell. It is a Lisp-like AST generation framework that comes as a GHC extension"<p>I'm only reminded of this quotation:<p><i>"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."<p>– Brian W. Kernighan</i>
Since macros are fundamentally just a poor man's higher order functions, Haskell really shouldn't need them.<p>For example, two major uses of macros in Lisp are with-macros and embedded DSLs. You don't need macros for either of those in Haskell, because first-class functions have you covered.