7 ms·

People spend time on this because Haskell syntax is deeply unpleasant to a lot of people, including myself. I love the capabilities and expressiveness of Haskel

People spend time on this because Haskell syntax is deeply unpleasant to a lot of people, including myself. I love the capabilities and expressiveness of Haskell, but I find the syntax annoying, and it hasn't gotten better even coming on three years of active Haskell programming. I've forgotten the $ in some usage of do or a final argument lambda twice in the last week even. I think it's worth solving these (superficial?) syntax issues even if they only affect the comfort of a third of all Haskell programmers.

massysett 10y ago
The problem is that ideas like this make the syntax even less readable.
- Peaker 10y ago
  It increases the regularity of the syntax (infix is not special) - and reduces $ noise which does not aid readability. I have been using Haskell for around a decade and hate every infix operator spam I have to throw in there to please this syntax irregularity. Other than this, I quite like Haskell syntax, but I remember initially hating it. It took many weeks to get used to it.
cfallin 10y ago
I wonder if anyone is working on a full rework of Haskell's syntax, a la Facebook's Reason for OCaml? I'm a big fan of the semantics but not as much the syntax of Haskell, too, and it would be interesting to see what a more... current-day-mainstream... syntax (Rust-like braces-and-semicolons-expression-based-language style, perhaps) would do for it.
- akhilcacharya 10y ago
  This would be absolutely amazing actually.
  - platz 10y ago
    Wait till you see a rust-style datatype polymorphic over 4 parameters, and use that type over and over again. Haskell syntax may not make much sense coming from algol-inspired syntax, but to express its patterns it makes sense otherwise you end up with scala type lambda madness. Both purescript and agda have this
    - cfallin 10y ago
      I'm curious, what sorts of issues arise with complex types that Haskell-like syntax handles better? (Genuinely curious here -- I've written a little Haskell but am by no means an expert...) IMHO a Rust-style type `Option<HashMap<String, Vec<u32>>>` is a little noiser than the Haskell-style type `Maybe (Map String [Int])`, but not fatally so. Maybe there are much worse cases though?
      - ryani 10y ago
        The big one is `->`; all the 'template argument'-inspired syntaxes for this are terrible. Once you realize you want operators (and polymorphic operators, at that!) in your types, the `<u32>`syntax falls apart. I am not a fan of C#'s `Func<a,b>` at all.
- DanWaterworth 10y ago
  This is what I'm doing with plastic [1], though it also has some semantic differences: strict instead of lazy, monads become objects. [1] https://github.com/DanielWaterworth/plastic https://github.com/DanielWaterworth/plastic
  - taylorfausak 10y ago
    That doesn't compile to Haskell.
    - DanWaterworth 10y ago
      I'm surprised that you expected it to. edit: Having looked at Reason more closely, I now see where the confusion came from. Sorry, I didn't mean to deceive you.
- chriswarbo 10y ago
  There was Liskell, but unfortunately it seems to be unmaintained :(
- iso-8859-1 10y ago
  https://github.com/lamdu/lamdu https://github.com/lamdu/lamdu
chriswarbo 10y ago
> People spend time on this because Haskell syntax is deeply unpleasant to a lot of people, including myself. I can understand that the syntax may be unpleasant, but I don't think having to memorise even more precedence rules makes a language more pleasant. When I read and write Haskell, my default "mode" is to see whitespace as function application, i.e. if I see "A B" then I assume "A" is being applied to "B". Hacks like "A $ B" interfere with this, since I have to mentally back-track and re-parse them as "$ (A) (B)". > I've forgotten the $ in some usage of do or a final argument lambda twice in the last week even. This is exactly the kind of thing I was lamenting. Rather than (ab)using "$", why not do the more natural thing, which every other language does, and use parentheses for grouping? Instead of "forgetting the $" in atomically do v <- readTVar tv writeTVar tv $! v + 1 Why not use parentheses for the job they're designed for, and write: atomically (do v <- readTVar tv writeTVar tv $! v + 1) Likewise, for withForeignPtr fptr \ptr -> c_memcpy buf ptr size You can use parentheses and never "forget the $" withForeignPtr fptr (\ptr -> c_memcpy buf ptr size) Parentheses are a universally understood syntax for grouping, they're supported in editors (e.g. finding matching pairs, checking if they're balanced, etc.), they always work in the same way, have no interference with other constructs or edge-cases, etc. Don't get me wrong, the "$" function is really useful, for example in "map ($ arg) [func1, func2, func3]", but I don't see the point of abusing it to avoid parentheses. I do sometimes use it myself, but whenever there are multiple infix functions around, I'll tend to use "redundant" parentheses for grouping.
- cousin_it 10y ago
  Syntactically significant indentation doesn't mix well with parentheses. (That's why Python doesn't have multiline lambda, for example.) And Haskell's rules for indentation are much more complicated than Python's, so the interactions with parentheses are even worse. I'm not sure there's any single person who really understands all the edge cases. It's a complete clusterfuck, they better start afresh. C-style parentheses and curly braces are so much better for parsing, copy-paste, automatically generated code, etc.
  - chriswarbo 10y ago

massysett 10y ago

The problem is that ideas like this make the syntax even less readable.

Peaker 10y ago
It increases the regularity of the syntax (infix is not special) - and reduces $ noise which does not aid readability. I have been using Haskell for around a decade and hate every infix operator spam I have to throw in there to please this syntax irregularity. Other than this, I quite like Haskell syntax, but I remember initially hating it. It took many weeks to get used to it.

cfallin 10y ago

I wonder if anyone is working on a full rework of Haskell's syntax, a la Facebook's Reason for OCaml? I'm a big fan of the semantics but not as much the syntax of Haskell, too, and it would be interesting to see what a more... current-day-mainstream... syntax (Rust-like braces-and-semicolons-expression-based-language style, perhaps) would do for it.

akhilcacharya 10y ago
This would be absolutely amazing actually.
- platz 10y ago
  Wait till you see a rust-style datatype polymorphic over 4 parameters, and use that type over and over again. Haskell syntax may not make much sense coming from algol-inspired syntax, but to express its patterns it makes sense otherwise you end up with scala type lambda madness. Both purescript and agda have this
  - cfallin 10y ago
    I'm curious, what sorts of issues arise with complex types that Haskell-like syntax handles better? (Genuinely curious here -- I've written a little Haskell but am by no means an expert...) IMHO a Rust-style type `Option<HashMap<String, Vec<u32>>>` is a little noiser than the Haskell-style type `Maybe (Map String [Int])`, but not fatally so. Maybe there are much worse cases though?
    - ryani 10y ago
      The big one is `->`; all the 'template argument'-inspired syntaxes for this are terrible. Once you realize you want operators (and polymorphic operators, at that!) in your types, the `<u32>`syntax falls apart. I am not a fan of C#'s `Func<a,b>` at all.
DanWaterworth 10y ago
This is what I'm doing with plastic [1], though it also has some semantic differences: strict instead of lazy, monads become objects. [1] https://github.com/DanielWaterworth/plastic https://github.com/DanielWaterworth/plastic
- taylorfausak 10y ago
  That doesn't compile to Haskell.
  - DanWaterworth 10y ago
    I'm surprised that you expected it to. edit: Having looked at Reason more closely, I now see where the confusion came from. Sorry, I didn't mean to deceive you.
chriswarbo 10y ago
There was Liskell, but unfortunately it seems to be unmaintained :(
iso-8859-1 10y ago
https://github.com/lamdu/lamdu https://github.com/lamdu/lamdu

chriswarbo 10y ago

> People spend time on this because Haskell syntax is deeply unpleasant to a lot of people, including myself. I can understand that the syntax may be unpleasant, but I don't think having to memorise even more precedence rules makes a language more pleasant. When I read and write Haskell, my default "mode" is to see whitespace as function application, i.e. if I see "A B" then I assume "A" is being applied to "B". Hacks like "A $ B" interfere with this, since I have to mentally back-track and re-parse them as "$ (A) (B)". > I've forgotten the $ in some usage of do or a final argument lambda twice in the last week even. This is exactly the kind of thing I was lamenting. Rather than (ab)using "$", why not do the more natural thing, which every other language does, and use parentheses for grouping? Instead of "forgetting the $" in atomically do v <- readTVar tv writeTVar tv $! v + 1 Why not use parentheses for the job they're designed for, and write: atomically (do v <- readTVar tv writeTVar tv $! v + 1) Likewise, for withForeignPtr fptr \ptr -> c_memcpy buf ptr size You can use parentheses and never "forget the $" withForeignPtr fptr (\ptr -> c_memcpy buf ptr size) Parentheses are a universally understood syntax for grouping, they're supported in editors (e.g. finding matching pairs, checking if they're balanced, etc.), they always work in the same way, have no interference with other constructs or edge-cases, etc. Don't get me wrong, the "$" function is really useful, for example in "map ($ arg) [func1, func2, func3]", but I don't see the point of abusing it to avoid parentheses. I do sometimes use it myself, but whenever there are multiple infix functions around, I'll tend to use "redundant" parentheses for grouping.

cousin_it 10y ago
Syntactically significant indentation doesn't mix well with parentheses. (That's why Python doesn't have multiline lambda, for example.) And Haskell's rules for indentation are much more complicated than Python's, so the interactions with parentheses are even worse. I'm not sure there's any single person who really understands all the edge cases. It's a complete clusterfuck, they better start afresh. C-style parentheses and curly braces are so much better for parsing, copy-paste, automatically generated code, etc.
- chriswarbo 10y ago