Haskell infix syntax

[Jacob Carlborg]

On 2011-03-07 22:13, Andrei Alexandrescu wrote:
> 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

It's basically determined by the first character in the name of the 
method. Associativity it determined by the last character in the name, 
if it ends with a colon it's right associative, otherwise left.

Have a look at: http://www.scala-lang.org/docu/files/ScalaReference.pdf 
6.12.3 InfixOperations

-- 
/Jacob Carlborg