Hacker News Reader

Comment by theophrastus | Hacker News Reader

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

View on HN

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.

Just for the sake of discussion, what is actually wrong with the syntax you just invented?

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

> 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)

Conventions are as important as syntax when it comes to legibility of a language, so phrasing “M” as “Action” seemed a fair comparison. And if you want to be true to the semantics, you might write something like this:

    def M2 ((A1 => A2 => R) => M<A1> => M<A2> => M<R>) where Monad<M>

At which point the Haskell syntax is shorter. However, concision is not the goal—it’s merely a proxy for clarity.

> Conventions are as important as syntax when it comes to legibility of a language, so phrasing “M” as “Action” seemed a fair comparison.

But the conventions are whatever we want for a resyntacting no?

> However, concision is not the goal

I was answering a comment putting concision forward as reasons to dislike the alternate syntax.

Hey, I didn't say one was worse or better but merely suggested some arguments as to why one might dislike that signature.

Clearly, as you demonstrate, the syntax described can be shortened—but it wasn't.

And by the definition being tied to the implementation I mean that it's not possible to write, e.g.

    foo :: Type1
    bar :: Type2

    foo = ...
    bar = ...

> Hey, I didn't say one was worse or better but merely suggested some arguments as to why one might dislike that signature.

pekk asked what was wrong with the syntax.

> Clearly, as you demonstrate, the syntax described can be shortened—but it wasn't.

I didn't change the syntax in any way.

> And by the definition being tied to the implementation I mean that it's not possible to write, e.g.

'k.

Is that actually used? Global type inference I could see, but that seems odder.

Fair enough. I conflated syntax with convention.

It is used quite frequently, actually, e.g. in describing type classes.

Aw, the Rust people will be either happy or sad about this.

Both at once, I imagine. Compromises were struck, and I think they were quite reasonable.

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.

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.

Yeah, this is a good point. Both math and music have extremely ad-hoc and inconsistent syntax.

> easy to parse

There's a few things, like fixity declarations, that make parsing Haskell not quite as easy as it could be.

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/0...

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?ac... that for the newbie followed by 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.

But that has nothing to do with syntax beyond "infix operators are a thing".

> 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.

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

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` ...

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...

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).

Reply on news.ycombinator.com