6 ms·

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 cra

by mkehrt 11y ago

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

cousin_it 11y ago
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.
- dragonwriter 11y ago
  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.)
  - cousin_it 11y ago
    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.
    - deleted 11y ago
      [deleted]
  - efaref 11y ago
    Interesting that the two operators that aren't associative are the two that you don't typically write as operators in mathematics.
    - dragonwriter 11y ago
      > 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.)
- marcosdumay 11y ago
  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.
  - cousin_it 11y ago
    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?
    - deleted 11y ago
      [deleted]
    - marcosdumay 11y ago
      Well, I don't think it's important for FP in general, but most of Haskell's syntax depends on currying.

by mkehrt 11y ago

cousin_it 11y ago

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.

dragonwriter 11y ago
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.)
- cousin_it 11y ago
  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.
  - deleted 11y ago
    [deleted]
- efaref 11y ago
  Interesting that the two operators that aren't associative are the two that you don't typically write as operators in mathematics.
  - dragonwriter 11y ago
    > 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.)
marcosdumay 11y ago
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.
- cousin_it 11y ago
  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?
  - deleted 11y ago
    [deleted]
  - marcosdumay 11y ago
    Well, I don't think it's important for FP in general, but most of Haskell's syntax depends on currying.