[jfm3]

Right, but I can add a sub-language with lazy evaluation, infix operators, and application syntax to Lisp...

I fully recognize Haskell can do a very useful subset of the features of real dynamic syntax. It's still a proper subset though.

[loup-vaillant]

What do you mean by "dynamic"? Syntax happens at compile time, right? Different syntax can apply to different part of the source code, but that's still static. Did I miss something?

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

    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]

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

[jfm3]

I get it. `my_if` doesn't require separate recompilation of the functions that use it. Well played.

I still see a subset of the functionality of a language with macros over sexprs as the syntax. It will take me some time, however, to come up with a good terse reply to that issue that fits in these tiny text boxes. The gist would probably be; if one is going to really change the syntax of a language, the programs that use the changed bits have to be re-parsed at some point. That's somehow tautological.

[loup-vaillant]

I actually agree. If you want for instance some weird scoping rule like

   ; example taken from PG's On Lisp
   ; "it" refers to the big-long-expression
   ; "aif" stands for "anamorphic if"
   (aif big-long-expression
     (foo it)
     (bar it))

then combinator libraries won't cut it. Template Haskell might, however (but its' not standard, and besides our point).

Now my point is that the subset we speak of is easier to achieve through functions with lazy evaluation. Macros are more capable, but harder to deal with. This is magnified by Haskell's paranoid type system: functions are checked in ways macros aren't.

So my guess is that neither system dominates the other.