8 ms·

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 sub

• loup-vaillant 16y ago
  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 16y ago
    He probably means that the syntax can vary at compile time. An example: Actual code I wrote (for https://github.com/stucchio/Mp3FS 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 16y ago
      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 16y ago
        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 16y ago
    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 16y ago
      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.