March 06, 2011
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
> So I think it's not worth adding to D.

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

Bye,
bearophile
March 06, 2011
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
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
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
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
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
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
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
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