[jriddycuz]

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.

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.

[thu]

A chunk of Haskell syntax is directly available:

  $ ghci -XTemplateHaskell
  > :m + Language.Haskell.TH
  > d <- runQ . return $ FunD (mkName "f") [Clause [VarP $ mkName "x"] (NormalB (LitE (IntegerL 5))) []]
  > [d] <- runQ [d| f x = 5 |]

The two last lines define the same `d` AST.

I have written some TH lately, and while being boring, you can write the first line as easily as the second one.

A nice thing to do when writing your TH code is to use runIO and pprint to display the generated code as it is spliced.

[thedigitalengel]

This (the second) way of doing things looks much more sensible -- thanks!

[thedigitalengel]

That is very true, I'll definitely use TH only as a last resort. Perhaps it would be cleaner to output a list of tokens, which the compiler then parses. But then that is not much far away from generating a string. :)