Haskell infix syntax

[Jonathan M Davis]

On Sunday 06 March 2011 10:03:05 Tomek Sowiński wrote:
> bearophile bearophile napisał:
> > Haskell is full of function calls, so the Haskell designers have
> > used/invented several different ways to avoid some parenthesys in the
> > code.
> > 
> > From what I've seen if you remove some parenthesis well, in the right
> > places, the resulting code is less noisy, more readable, and it has less
> > chances to contain a bug (because syntax noise is a good place for bugs
> > to hide).
> > 
> > One of the ways used to remove some parenthesys is a standard syntax
> > that's optionally usable on any dyadic function (function with two
> > arguments):
> > 
> > sum a b = a + b
> > 
> > sum 1 5 == 1 `sum` 5
> > 
> > The `name` syntax is just a different way to call a regular function with
> > two arguments.
> > 
> > In Haskell there is also a way to assign an arbitrary precedence and
> > associativity to such infix operators, but some Haskell programmers
> > argue that too much syntax sugar gives troubles (
> > http://www.haskell.org/haskellwiki/Use_of_infix_operators ).
> > 
> > In D the back tick has a different meaning, and even if in D you use a
> > different syntax, like just a $ prefix, I don't know how much good this
> > syntax is for D:
> > 
> > int sum(int x, int y) { return x + y; }
> > 
> > int s = sum(1, sum(5, sum(6, sum(10, 30))));
> > Equals to (associativity of $ is fixed like this):
> > int s = 1 $sum 5 $sum 6 $sum 10 $sum 30;
> > 
> > So I think it's not worth adding to D.
> 
> I vaguely recall someone mentioned infixablility by naming convention.
> 
> int _add_(int x, int y);
> 
> int s = 1 _add_ 5 _add_ 10;
> 
> As a feature of its own, it's just sugar. But if introducing infix
> operators were contingent on banishing classic operator overloading, then
> it is worthwhile.

LOL. And _what_ benefit would banishing classic operator overloading have? A 
function named add could be abused in _exactly_ the same ways that + can be.

The main benefit that infix syntax would provide would be if you had a variety of 
mathematical functions beyond what the built in operators give you, and you want 
to be able to treat them the same way. Whether classic operator overloading 
exists or not is irrelevant.

Regardless, I don't think that adding infix syntax to the language is worth it. D 
is already pretty complicated and _definitely_ more complicated than most 
languages out there. One of the major complaints of C++ is how complicated it 
is. We don't want to be adding extra complexity to the language without the 
benefit outweighing that complexity, and I don't think that it's at all clear 
that it does in this case. As as KennyTM~ pointed out, if UFCS is ever 
implemented, it gives you most of the benefit of this anyway, and there are 
already a lot of people around here interested in UFCS. So, I find it _far_ more 
likely that UFCS gets implemented than an infix function call syntax.

- Jonathan M Davis