Haskell infix syntax

[Tomek Sowiński]

Jonathan M Davis napisał:

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

I've worked on a financial system written in Java which used BigDecimal extensively. And, of course, I LOLed at that. But after having spent time with the code, a few benefits surfaced. It was clear which function was user-implemented. Displaying the docs by mousing over was nice too (outside the IDE grepping 'add' is easier than '+'). And above all, no abuse whatsoever. It all didn't outweigh the loss in terseness of syntax but did make up for some of it.

I'm bringing up this case because it's extremely in favour of operator overloading. Java is not big on number crunching and BigDecimal is one of the few spots on the vast programming landscape where overloaded operators make sense. And yet, the final verdict was: it doesn't suck.

> A function named add could be abused in _exactly_ the same ways that + can be.

There's far less incentive for abuse as there's no illusory mathematical elegance to pursue.

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

That's mixing vect1 + vect2 with vect1 `dot` vect2. I'd rather see them treated the same way.

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

I agree. Hence the idea of trading operator overloading for infixing. The added complexity is zero, if not less.

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

I also think it is more probable.

-- 
Tomek