Hacker News Reader

Comment by mkehrt | Hacker News Reader

As someone who has done a lot of work with ML and the lambda calculus, having to put parentheses around my arguments in most programming languages drives me crazy. It feels so heavyweight.

Function argument parens are particularly weird when dealing with curried arguments. `f x y z` is so much nicer than `f(x)(y)(z)`.

View on HN

Naw. I hate using whitespace for function application. Having a binary operation that's neither associative nor parenthesized is super confusing to newbies.

   a+b+c = (a+b)+c = a+(b+c)  // Good!
   f a b = (f a) b != f (a b)  // WTF?

BTW, that's also a good rule of thumb for defining new operators. If your new op ~-^-~ is not associative, don't make it an op!! And even if it is, consider that users won't magically know the relative precedence of your op versus someone else's =^%^=. Looking at you, Haskell.

You provide:

   a+b+c = (a+b)+c = a+(b+c)  // Good!
   f a b = (f a) b != f (a b)  // WTF?

So, I suppose, also:

   a/b/c = (a/b)/c != a/(b/c) // WTF?

> BTW, that's also a good rule of thumb for defining new operators. If your new op ~-^-~ is not associative, don't make it an op!!

Why should associativity be a requirement for a new op? Its not universal among common standard binary operators, after all (particularly division and exponentiation are not associative.)

I said either associative or parenthesized. People don't write a/b/c because they had 10 years of learning to use parens in arithmetic, but they write f a b all the time. For the same reason, my rule of thumb applies only to operators that you define.

The non-associativity of exponentiation does throw people off sometimes. Not all college students will correctly parse 2^2^2. IMO it's a wart in math notation. It could've been easily avoided by e.g. drawing a box around the exponent, so stacked exponentials would have boxes nesting upward.

Interesting that the two operators that aren't associative are the two that you don't typically write as operators in mathematics.

> Interesting that the two operators that aren't associative are the two that you don't typically write as operators in mathematics.

Sure, for those two examples, but plenty of things that are typically written as operators in math aren't associative (× as the cross product, for instance, which gets bonus points for overloading a symbol that is an associative operator in other contexts.)

In fact a lot of (.) and ($) messing would simply go away if Haskell used the old normal syntax for functions.

But then, this notation overloads the parenthesis, what is bad, and would make currying extremely annoying, basically killing the language.

Anyway, I disagree with you about operators. Some operations are just clearer when infixed, and there's no reason at all to expect a random operator to associative. Now, right associative operators are indeed something to use with care.

This might be veering off topic, but I never really bought the argument that currying is important to FP. It seems more like a toy that makes some code marginally shorter, but interferes with other useful things (like named or default arguments). Or is there something fundamental that I'm missing?

Well, I don't think it's important for FP in general, but most of Haskell's syntax depends on currying.

Reply on news.ycombinator.com