Oh Haskell, why must you hurt my brain so much?

I get that it's a powerful language, that 2 characters of Haskell can do more than a gigabytes of C (or something like that I'm told). Im even trying to learn the language. But until then, I am always stuck with the impression (usually correct) that I just don't get it, when something discussing it comes along. :(

I think Real World Haskell might help you with that, and after that, The Road to Mathematics and Logic.

My main problem with RWH (and I'm not alone in saying this) is that the first 4 chapters are insufficient to prepare you for the material in the rest of the book.

Read "Programming in Haskell" by Graham Hutton first. It's a small book... I literally did the whole thing (including implementing all the exercises) in a week. To call it excellent would be the understatement of the century.

From there, pick up RWH. You can skim the first few chapters, and you'll be much better equipped to read the rest of them.

Thanks for the pointers!

Can anyone tell me what the main barriers are to providing the functionality of Lisp style macros in Haskell? Not being particularly well versed in either, I'm guessing it is something to do with the regularity of Lisp syntax, or some fundamental difficulties with providing macros in a statically typed language? Is it likely that Haskell could be extended to support them in the future? I've heard of Template Haskell, does this provide the same functionality as macros?

There are no barriers to providing Lisp-style macros other than the lack of Lisp-style syntax. You can use Liskell if you want to write Lisp style macros that are compiled with the usual GHC machinery, or you can use TH if you want to write "Haskell-style" macros.

There is one huge barrier -- the total inability to do runtime type-checks makes many types of macros impossible to do in the Lisp style (type-erasure means you can't even cheat).

PolyP lead to GenericHaskell which lead to Template Haskell, which is now included with GHC. They let you write generic functions that are passed the types of their arguments as a value alongside them, and then at compile-compile-time they are templated out into vanilla Haskell functions specialized on each argument type.

Interesting. What about OCaml? I assume they have some kind of macro support. Assuming it is not as simple to work with as Lisp, how does it compare to the "Haskell-style" macros of Template Haskell?

OCaml comes with (and is implemented using) camlp4 -- it's an extraordinarily powerful "Pre-Processor-Pretty-Printer" that operates directly on a concrete syntax for the language.

Classical Lisp macros are only 'cleaner' by cheating.

Most of Template Haskell is about solving a different problem (A statically-type-checked meta-language for generating code that must be statically type-checked) -- and thus is pretty messy. It's still way cleaner than any of its predecessors (at least of the ones I've used).

Yes, note also that Haskell itself is the Template Haskell metalanguage. I.e. Haskell programs use Haskell to modify their own AST at compile time, giving you arbitrary AST power.

I'd say the barrier number one is the lack of usefulness. Because of the non-strict nature of Haskell, many macros are usefull in Lisp and useless in Haskell, because you can write plain functions instead.