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

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);

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

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.

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

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.