View mode: basic / threaded / horizontal-split · Log in · Help
March 06, 2011
Haskell infix syntax
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.

Bye,
bearophile
March 06, 2011
Re: Haskell infix syntax
> So I think it's not worth adding to D.

But if you don't agree... talk.

Bye,
bearophile
March 06, 2011
Re: Haskell infix syntax
On Mar 7, 11 00:18, bearophile wrote:
> 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.
>
> Bye,
> bearophile

If we had UFCS this could be written as,

    int s = 1.sum(5.sum(6.sum(10.sum(30))));

or, knowing sum is associative,

    int s = 1.sum(5).sum(6).sum(10).sum(30);
March 06, 2011
Re: Haskell infix syntax
KennyTM~:

> If we had UFCS this could be written as,

UFCS is a huge hack that I hope to never see in D :-)
Compared to it, the bad-looking $infix syntax I've just shown is tidy and safe.

Bye,
bearophile
March 06, 2011
Re: Haskell infix syntax
bearophile:
> UFCS is a huge hack that I hope to never see in D :-)

How is it a hack? I can understand there being implementation problems
that can make it undesirable to add, but calling it hack?

It's one of the most elegant syntax proposals I've ever seen! It
unifies objects and other functions in syntax. It improves
encapsulation by giving full support to non-member functions. It
improves modularity for the same reason.

With ufcs, there'd be no desire to add useless members due to
object syntax. Everything is equal - easy extensibility, better
protection, cleaner interfaces.

It's the opposite of a hack.
March 06, 2011
Re: Haskell infix syntax
bearophile <bearophileHUGS@lycos.com> wrote:

>> So I think it's not worth adding to D.
>
> But if you don't agree... talk.

This is basically already possible in D:

struct InfixOperator( alias fn ) {
    auto opBinaryRight( string op : "/", T )( T lhs ) {
        struct crazy {
            T value;
            auto opBinary( string op : "/", U )( U rhs ) {
                return fn( rhs, value );
            }
        }
        return crazy(lhs);
    }
}

@property auto _( alias fn )( ) {
    return InfixOperator!fn( );
}

T add( T )( T a, T b ) {
	return a + b;
}
unittest {
    assert( 2 /_!add/ 3 == 5 );
}



-- 
Simen
March 06, 2011
Re: Haskell infix syntax
Simen kjaeraas <simen.kjaras@gmail.com> wrote:

> This is basically already possible in D:

Please do note that this was intended more as a challenge
to myself than as a legitimate Good Idea.

-- 
Simen
March 06, 2011
Re: Haskell infix syntax
Simen kjaeraas:

> This is basically already possible in D:

I suggest you to stop using the single underscore as identifier.


> unittest {
>      assert( 2 /_!add/ 3 == 5 );
> }

OK. Now let's go back to Haskell :-)

Thank you for your answer,
bye,
bearophile
March 06, 2011
Re: Haskell infix syntax
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.

-- 
Tomek
March 06, 2011
Re: Haskell infix syntax
On 6/03/11 4:22 PM, bearophile wrote:
>> So I think it's not worth adding to D.
>
> But if you don't agree... talk.
>
> Bye,
> bearophile

I agree.

It would be nice in some situations (like cross and dot products for 
vectors), but otherwise it's unnecessary and just adds confusion in 
exchange for a tiny but of convenience in a handful of scenarios.
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home