9 ms·

syntax. of the dozen languages i've taught myself, (which is a super-set of the half dozen i've used to write significant things), Haskell's syntax has been, an

syntax. of the dozen languages i've taught myself, (which is a super-set of the half dozen i've used to write significant things), Haskell's syntax has been, and remains, the largest barrier for me (and this includes perl!). For example, just a clear equivalence, like this one given by the very helpful linked article here, would've helped enormously ("sugared form" for monad): do { a <- f ; m } ≡ f >>= \a -> do { m } Sometimes i think the authors of Haskell had a completely different glyph set. I'm sure some of you folks can read this like a book, but this sort of thing still throws me into the ditch: M2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r

BadassFractal 11y ago
It takes a while to master reading math notation or music notation. Mastering reading Haskell isn't that different. Some people are served well enough by just learning guitar tabs, others feel they're better off mastering music notation.
- skimpycompiler 11y ago
  This is not true, unlike C++, Haskell's syntax is enormously clean and easy to parse. It's in no way comparable to learning math notation or music notation.
  - bsummer4 11y ago
    Yeah, this is a good point. Both math and music have extremely ad-hoc and inconsistent syntax.
  - pdpi 11y ago
    > easy to parse There's a few things, like fixity declarations, that make parsing Haskell not quite as easy as it could be.
  - cousin_it 11y ago
    IMO there are many nice things about Haskell, but simplicity is not one of them. It's very consciously a "big" language, rather than a "small" one. As others have mentioned, you can declare your own operators with custom precedence. And don't forget the whitespace rules either. Lennart Augustsson, implementor of at least one Haskell compiler, has said this at some point: Implementing exactly Haskell's rule for indentation is incredibly hard. In fact, no known Haskell compiler gets it right. https://mail.haskell.org/pipermail/haskell-cafe/2009-April/060657.html https://mail.haskell.org/pipermail/haskell-cafe/2009-April/0...
- iheartmemcache 11y ago
  APL/J/K is way more "operator soup-y" than Haskell, but there are pages like this http://www.jsoftware.com/jwiki/action/show/Vocabulary/AET?action=show&redirect=Vocabulary%2FAbsolutelyEssentialTerms#VerbRank http://www.jsoftware.com/jwiki/action/show/Vocabulary/AET?ac... that for the newbie followed by http://www.jsoftware.com/jwiki/NuVoc http://www.jsoftware.com/jwiki/NuVoc. Someone needs to make Typeclassopedia for operator soup. For the record, I can read both standard notation music and guitar tabs. I'm fairly competent at Haskell have written APL/J/K derivative languages for a living. "Mastering reading Haskell" certainly has to do with a lack of "go to this page on the wiki/hoogle/haddock and you can read the meaning and idiomatic usage of the 95% most common operators", not a lack of conceptual grasp of anything difficult.
  - jberryman 11y ago
    But that has nothing to do with syntax beyond "infix operators are a thing".
coolsunglasses 11y ago
This is my favorite post on desugaring Haskell syntax: http://www.haskellforall.com/2014/10/how-to-desugar-haskell-code.html http://www.haskellforall.com/2014/10/how-to-desugar-haskell-...
evincarofautumn 11y ago
Well, just for the sake of discussion, would you prefer something like this? def M2<T1, T2, Result, Action : Monad>( f: (T1, T2) => Result, a: Action<T1>, b: Action<T2>): Action<Result> { … } The Haskell notation is a simple, concise representation of the actual semantics. If you try to transpose those semantics to a more conventional notation intended for different semantics, it gets complicated due to the mismatch. This notation I’ve suggested doesn’t even accurately express such details as currying and typeclasses, which the original notation conveys neatly.
- pekk 11y ago
  Just for the sake of discussion, what is actually wrong with the syntax you just invented?
  - deleted 11y ago
    [deleted]
  - tel 11y ago
    Here are a few possible complaints: 1. It's way longer 2. Naming the monad "Action" may be misleading depending on choice of Monad 3. It's tied syntactically to the syntax of the implementation 4. The <>s are superfluous 5. The argument names are superfluous (to the type) 6. The explicit type quantification is superfluous and verbose
    - masklinn 11y ago
      > It's way longer Because of the much longer type names which have nothing to do with the syntax. By just replacing all the type names by the original single-letter names, it goes from 107 to 72 characters, that's almost 50% increase in size (49%) due to longer type names, which incidentally is nearly double the increase in size between the Haskell signature and this new signature (57 -> 72, or 26%) def M2<A1, A2, R, M: Monad>(f: (A1, A2) => R, a: M<A1>, b: M<A2>): M<R> Funnily enough, this expansion is relatively worse if applied to the Haskell signature (57 -> 87, +53%) > Naming the monad "Action" may be misleading depending on choice of Monad Nothing to do with syntax either. > It's tied syntactically to the syntax of the implementation ? > The argument names are superfluous (to the type) That can trivially be removed when just displaying the function's type (`f`'s arguments are not explicitly named after all), likewise for the unnecessary type quantifications, so a type-view of this function (rather than a source view) could be: def M2<M: Monad>((A1, A2) => R, M<A1>, M<A2>) => M<R> Oh look, it's now shorter than the original signature (though somewhat more noisy, I'll give you that)
dragonwriter 11y ago
> Sometimes i think the authors of Haskell had a completely different glyph set. Well, its an ML-derived syntax rather than the more common Algol-derived syntax, which forms something of a familiarity obstacle for programmers whose background is largely in Algol-derived syntaxes. Its probably somewhat easier if you've learned another ML family language first -- especially given that idiomatic Haskell often involves wrapping your head around semantics that are unfamiliar as well, so that you aren't trying to take on both at once. OTOH, I think the kind of ML-based syntax Haskell uses is a good fit, and its worth learning.
yawaramin 11y ago
It's funny you should ask this, because you're right that some types really are quite hard to read and there was a great discussion a few days ago where someone mentioned that the types tell you a lot about what the function is doing, and then someone retorted that most examples of types guiding you are usually very simple, and posted a really complex type for people to decipher, and the more proficient Haskellers actually worked it out--based partly on their previous knowledge of similar types! See http://www.reddit.com/r/haskell/comments/3ijtej/any_tips_for_reading_haskell_code/cuh36rm http://www.reddit.com/r/haskell/comments/3ijtej/any_tips_for... Now, I'm not at that level of proficiency, but I can tell that your example above takes a binary function and 'lifts' it into a higher (monadic) context, so that it can work on monadic values. And the reason I can work this out is because I know about the Functor typeclass which has the function fmap :: (a -> b) -> f a -> f b, which does a similar job of lifting an input function into a higher context (in this case a functor context).
spopejoy 11y ago
But ... but ... Haskell has the least syntax of any "mainstream" language (save LISP, without macros). Your example of course is `do` notation which is tricky, and is really kind of advanced -- it's much better to use `>>=` `>>` and `return` as long as you can stand before breaking out `do`. If nothing else avoiding `do` will make you write smaller functions! By "syntax" of course I mean "keywords". Haskell allows for infix operator creativity which you might see as a drawback. I would rather have a language be maximally expressive, allow me to define my own infix swear-word "operators", than be coddled and censored like almost every other language outside C++. But as for built-in syntax, there's hardly any. `$` and `.` are freaking library functions. As for types, well, types are hard to read. Why shouldn't they be? It's not like templates are easy in C++ once you leave the most trivial exercises. At least Haskell's are formally consistent and fundamentally related to your definitions -- unlike templates which are really macro soup. In any case, I would find your `M2` definition a lot easier to read with `a` and `b` instead of `a1` and `a2` ...

BadassFractal 11y ago

It takes a while to master reading math notation or music notation. Mastering reading Haskell isn't that different. Some people are served well enough by just learning guitar tabs, others feel they're better off mastering music notation.

skimpycompiler 11y ago
This is not true, unlike C++, Haskell's syntax is enormously clean and easy to parse. It's in no way comparable to learning math notation or music notation.
- bsummer4 11y ago
  Yeah, this is a good point. Both math and music have extremely ad-hoc and inconsistent syntax.
- pdpi 11y ago
  > easy to parse There's a few things, like fixity declarations, that make parsing Haskell not quite as easy as it could be.
- cousin_it 11y ago
  IMO there are many nice things about Haskell, but simplicity is not one of them. It's very consciously a "big" language, rather than a "small" one. As others have mentioned, you can declare your own operators with custom precedence. And don't forget the whitespace rules either. Lennart Augustsson, implementor of at least one Haskell compiler, has said this at some point: Implementing exactly Haskell's rule for indentation is incredibly hard. In fact, no known Haskell compiler gets it right. https://mail.haskell.org/pipermail/haskell-cafe/2009-April/060657.html https://mail.haskell.org/pipermail/haskell-cafe/2009-April/0...
iheartmemcache 11y ago
APL/J/K is way more "operator soup-y" than Haskell, but there are pages like this http://www.jsoftware.com/jwiki/action/show/Vocabulary/AET?action=show&redirect=Vocabulary%2FAbsolutelyEssentialTerms#VerbRank http://www.jsoftware.com/jwiki/action/show/Vocabulary/AET?ac... that for the newbie followed by http://www.jsoftware.com/jwiki/NuVoc http://www.jsoftware.com/jwiki/NuVoc. Someone needs to make Typeclassopedia for operator soup. For the record, I can read both standard notation music and guitar tabs. I'm fairly competent at Haskell have written APL/J/K derivative languages for a living. "Mastering reading Haskell" certainly has to do with a lack of "go to this page on the wiki/hoogle/haddock and you can read the meaning and idiomatic usage of the 95% most common operators", not a lack of conceptual grasp of anything difficult.
- jberryman 11y ago
  But that has nothing to do with syntax beyond "infix operators are a thing".

coolsunglasses 11y ago

This is my favorite post on desugaring Haskell syntax: http://www.haskellforall.com/2014/10/how-to-desugar-haskell-code.html http://www.haskellforall.com/2014/10/how-to-desugar-haskell-...

evincarofautumn 11y ago

Well, just for the sake of discussion, would you prefer something like this? def M2<T1, T2, Result, Action : Monad>( f: (T1, T2) => Result, a: Action<T1>, b: Action<T2>): Action<Result> { … } The Haskell notation is a simple, concise representation of the actual semantics. If you try to transpose those semantics to a more conventional notation intended for different semantics, it gets complicated due to the mismatch. This notation I’ve suggested doesn’t even accurately express such details as currying and typeclasses, which the original notation conveys neatly.

pekk 11y ago
Just for the sake of discussion, what is actually wrong with the syntax you just invented?
- deleted 11y ago
  [deleted]
- tel 11y ago
  Here are a few possible complaints: 1. It's way longer 2. Naming the monad "Action" may be misleading depending on choice of Monad 3. It's tied syntactically to the syntax of the implementation 4. The <>s are superfluous 5. The argument names are superfluous (to the type) 6. The explicit type quantification is superfluous and verbose
  - masklinn 11y ago
    > It's way longer Because of the much longer type names which have nothing to do with the syntax. By just replacing all the type names by the original single-letter names, it goes from 107 to 72 characters, that's almost 50% increase in size (49%) due to longer type names, which incidentally is nearly double the increase in size between the Haskell signature and this new signature (57 -> 72, or 26%) def M2<A1, A2, R, M: Monad>(f: (A1, A2) => R, a: M<A1>, b: M<A2>): M<R> Funnily enough, this expansion is relatively worse if applied to the Haskell signature (57 -> 87, +53%) > Naming the monad "Action" may be misleading depending on choice of Monad Nothing to do with syntax either. > It's tied syntactically to the syntax of the implementation ? > The argument names are superfluous (to the type) That can trivially be removed when just displaying the function's type (`f`'s arguments are not explicitly named after all), likewise for the unnecessary type quantifications, so a type-view of this function (rather than a source view) could be: def M2<M: Monad>((A1, A2) => R, M<A1>, M<A2>) => M<R> Oh look, it's now shorter than the original signature (though somewhat more noisy, I'll give you that)

dragonwriter 11y ago

> Sometimes i think the authors of Haskell had a completely different glyph set. Well, its an ML-derived syntax rather than the more common Algol-derived syntax, which forms something of a familiarity obstacle for programmers whose background is largely in Algol-derived syntaxes. Its probably somewhat easier if you've learned another ML family language first -- especially given that idiomatic Haskell often involves wrapping your head around semantics that are unfamiliar as well, so that you aren't trying to take on both at once. OTOH, I think the kind of ML-based syntax Haskell uses is a good fit, and its worth learning.

yawaramin 11y ago

It's funny you should ask this, because you're right that some types really are quite hard to read and there was a great discussion a few days ago where someone mentioned that the types tell you a lot about what the function is doing, and then someone retorted that most examples of types guiding you are usually very simple, and posted a really complex type for people to decipher, and the more proficient Haskellers actually worked it out--based partly on their previous knowledge of similar types! See http://www.reddit.com/r/haskell/comments/3ijtej/any_tips_for_reading_haskell_code/cuh36rm http://www.reddit.com/r/haskell/comments/3ijtej/any_tips_for... Now, I'm not at that level of proficiency, but I can tell that your example above takes a binary function and 'lifts' it into a higher (monadic) context, so that it can work on monadic values. And the reason I can work this out is because I know about the Functor typeclass which has the function fmap :: (a -> b) -> f a -> f b, which does a similar job of lifting an input function into a higher context (in this case a functor context).

spopejoy 11y ago

But ... but ... Haskell has the least syntax of any "mainstream" language (save LISP, without macros). Your example of course is `do` notation which is tricky, and is really kind of advanced -- it's much better to use `>>=` `>>` and `return` as long as you can stand before breaking out `do`. If nothing else avoiding `do` will make you write smaller functions! By "syntax" of course I mean "keywords". Haskell allows for infix operator creativity which you might see as a drawback. I would rather have a language be maximally expressive, allow me to define my own infix swear-word "operators", than be coddled and censored like almost every other language outside C++. But as for built-in syntax, there's hardly any. `$` and `.` are freaking library functions. As for types, well, types are hard to read. Why shouldn't they be? It's not like templates are easy in C++ once you leave the most trivial exercises. At least Haskell's are formally consistent and fundamentally related to your definitions -- unlike templates which are really macro soup. In any case, I would find your `M2` definition a lot easier to read with `a` and `b` instead of `a1` and `a2` ...