Search
Mar 06, 2011
bearophile
Mar 06, 2011
bearophile
Mar 06, 2011
Simen kjaeraas
Mar 06, 2011
Simen kjaeraas
Mar 06, 2011
bearophile
Mar 07, 2011
Simen kjaeraas
Mar 06, 2011
Peter Alexander
Mar 07, 2011
Caligo
Mar 07, 2011
Tomek Sowiński
Mar 09, 2011
Gareth Charnock
Mar 06, 2011
KennyTM~
Mar 06, 2011
bearophile
Mar 06, 2011
Mar 07, 2011
Jonathan M Davis
Mar 07, 2011
bearophile
Mar 06, 2011
Tomek Sowiński
Mar 07, 2011
Jonathan M Davis
Mar 07, 2011
Jacob Carlborg
Mar 07, 2011
spir
Mar 07, 2011
KennyTM~
Mar 07, 2011
KennyTM~
Mar 07, 2011
Jacob Carlborg
Mar 07, 2011
Tomek Sowiński
```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
```
```> So I think it's not worth adding to D.

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

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 <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
```
```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
```
```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 :-)

bye,
bearophile
```
```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.
```
« First   ‹ Prev
1 2 3