Macros in Haskell

[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]

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. :)

[jberryman]

I'm still a TH newbie, but i collected a couple of tricks for working with TH interactively in GHCi on my blog:

http://coder.bsimmons.name/blog/2010/12/working-with-templat...

[jrockway]

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.

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.)

[pjscott]

My favorite is the MessagePack serialization protocol. The Haskell implementation (officially supported, yay) uses Template Haskell to derive serialization and deserialization code, with full type-checking, for arbitrary data structures. Check it out:

https://github.com/msgpack/msgpack/blob/master/haskell/test/...

[thedigitalengel]

There is a list here: http://www.haskell.org/haskellwiki/Template_Haskell#Projects

I'm a Haskell newbie, and have not done much with TH yet. But I can imagine a bunch of TH code generating a lexer or a parser out of some meta-description. Like Happy, but with everything directly embedded in the source itself.

[ableal]

"Haskell too has macros. The subsystem is called Template Haskell. It is a Lisp-like AST generation framework that comes as a GHC extension"

I'm only reminded of this quotation:

"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."

– Brian W. Kernighan

[waqf]

Since macros are fundamentally just a poor man's higher order functions, Haskell really shouldn't need them.

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.

[gujk]

Haskell does not support unboundedly highly kinded types (or whatever it is called).

There is no direct way in base Haskell to declare all of 1- to 10-tuples with a single type declaration in a map or loop, for example. Template Haskell can do this, though.