Haskell infix syntax

[Andrei Alexandrescu]

On 3/7/11 5:05 AM, Jacob Carlborg wrote:
> On 2011-03-07 01:10, Jonathan M Davis wrote:
>> 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.
>
> You could implement operator overloading without any special
> cases/support in the language, like Scala does. In Scala
>
> 3 + 4
>
> Is syntax sugar for:
>
> 3.+(4)
>
> It's possible because of the following three reasons:
>
> * Everything is an object
> * Method names can contain other characters than A-Za-z_
> * The infix syntax discussed in this thread
>
> Implementing operator overloading like this also allows you to add new
> operators and not just overloading existing ones.

How about precedence?

Andrei