On: Haskell’s Niche: Hard Problems

[yummyfajitas]

He probably means that the syntax can vary at compile time. An example:

Actual code I wrote (for https://github.com/stucchio/Mp3FS ):

    type Mp3fsM a = ReaderT Mp3fsInternalData IO a

    runMp3fsM  f r = runReaderT f r
    runMp3fsM1 f r = \x -> runReaderT (f x) r
    runMp3fsM2 f r = \x -> \y -> runReaderT (f x y) r
    runMp3fsM3 f r = \x -> \y -> \z -> runReaderT (f x y z) r
    runMp3fsM4 f r = \x -> \y -> \z -> \t -> runReaderT (f x y z t) r

In lisp, this sort of thing could be handled by a macro.

[kwantam → yummyfajitas]

    In lisp, this sort of thing could be handled by a macro.

So why not apples-to-apples and use Template Haskell to do it?

[loup-vaillant → kwantam]

Because it doesn't fit my original argument, that Haskell's combinatorial approach can do much (though not all) of what Lisp macros do.