March 07, 2011
On Sunday 06 March 2011 09:34:07 Adam D. Ruppe wrote:
> 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.

It is _not_ a hack. Whether it's desirable or not is another matter, but it is _not_ a hack. And really, the term hack is very imprecise and often subjective. It's the sort of accusation that pretty much kills any legitimate debate. It's generally unsupportable and subjective, so it adds nothing to the debate, but it has such a stink about it that it tends to make people avoid whatever was declared to be a hack.

Sure, you still have lots of parens with UFCS, but you _do_ get the argument order that Bearophile was looking for. And while I've generally found the idea of using UFCS with primitives to be pointless, this is actually an example where it's _useful_ with primitives.

No, UFCS is not a hack. Its implementation has enough problems due to ambiguities and the like that it may never make it into the language even if pretty much everyone would _like_ it in the language, but it's not a hack.

- Jonathan M Davis




P.S. Entertainingly enough, www.merriam-webster.com's definition for hack doesn't make it look bad at all:

"a usually creative solution to a computer hardware or programming problem or limitation"

It makes me wonder if the usage of the word (and thus its common meaning) has shifted over time or if the poor non-techy, dictionary folk just plain got it wrong. The hacker's dictionary definition makes it look more like the typical usage, but even it is a bit of a mixed bag in that respect:

1. /n./ Originally, a quick job that produces what is needed, but not well.
2. /n./ An incredibly good, and perhaps very time-consuming, piece of work that
produces exactly what is needed.
March 07, 2011
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.

The main benefit that infix syntax would provide would be if you had a variety of mathematical functions beyond what the built in operators give you, and you want to be able to treat them the same way. Whether classic operator overloading exists or not is irrelevant.

Regardless, I don't think that adding infix syntax to the language is worth it. D is already pretty complicated and _definitely_ more complicated than most languages out there. One of the major complaints of C++ is how complicated it is. We don't want to be adding extra complexity to the language without the benefit outweighing that complexity, and I don't think that it's at all clear that it does in this case. As as KennyTM~ pointed out, if UFCS is ever implemented, it gives you most of the benefit of this anyway, and there are already a lot of people around here interested in UFCS. So, I find it _far_ more likely that UFCS gets implemented than an infix function call syntax.

- Jonathan M Davis
March 07, 2011
Jonathan M Davis:

> And really, the term hack is very imprecise and often subjective. It's the sort of accusation that pretty much kills any legitimate debate.

You are right, sorry for using a so subjective term. I will avoid it.

Bye,
bearophile
March 07, 2011
On Sun, Mar 6, 2011 at 12:24 PM, Peter Alexander <peter.alexander.au@ gmail.com> wrote:

> 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.
>


With C++, for example, Eigen uses expression templates.  How does one do expression templates in D? Could someone rewrite this http://en.wikipedia.org/wiki/Expression_templates this D?


March 07, 2011
On 3/6/11 6:04 PM, Jonathan M Davis wrote:
> On Sunday 06 March 2011 09:34:07 Adam D. Ruppe wrote:
>> 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.
>
> It is _not_ a hack. Whether it's desirable or not is another matter, but it is
> _not_ a hack. And really, the term hack is very imprecise and often subjective.
> It's the sort of accusation that pretty much kills any legitimate debate. It's
> generally unsupportable and subjective, so it adds nothing to the debate, but it
> has such a stink about it that it tends to make people avoid whatever was
> declared to be a hack.

I set out to write a post with pretty much the same message. During our long discussions about D2 at the Kahili coffee shop, one of us would occasionally affix that label to one idea or another (often in an attempt to make "I don't like it" seem stronger). It was very jarring.

Andrei
March 07, 2011
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.

-- 
/Jacob Carlborg
March 07, 2011
On 03/07/2011 02:05 PM, Jacob Carlborg wrote:
> 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.

We could give a standard name to each character in an allowed class, so that
	x !%# y
maps to
	x.opBangPercentHash(y);
;-)
Another solution is to specify operators in method defs:
	X opBangPercentHash as "!%#" (X y) {...}
Or even use them directly there:
	X !%# (X y) {...}
possibly with an annotation to warn the parser:
	@operator X !%# (X y) {...}
In any case, /this/ is not a big deal to manage in symbol tables, since an operator is just a string like (any other) name. The big deal is to map such features to builtin types, I guess (which are not object types).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

March 07, 2011
On Mar 7, 11 21:44, spir wrote:
> On 03/07/2011 02:05 PM, Jacob Carlborg wrote:
>> 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.
>
> We could give a standard name to each character in an allowed class, so
> that
> x !%# y
> maps to
> x.opBangPercentHash(y);
> ;-)

The current opBinary syntax already allows this ;)

Bar opBinary(string op:"!%#")(Foo y) const {
  ...
}

> Another solution is to specify operators in method defs:
> X opBangPercentHash as "!%#" (X y) {...}
> Or even use them directly there:
> X !%# (X y) {...}
> possibly with an annotation to warn the parser:
> @operator X !%# (X y) {...}
> In any case, /this/ is not a big deal to manage in symbol tables, since
> an operator is just a string like (any other) name. The big deal is to
> map such features to builtin types, I guess (which are not object types).
>

The big deal is it makes parsing more difficult (precedence and associativity need to be determined) with no significant benefit.

> Denis


March 07, 2011
bearophile <bearophileHUGS@lycos.com> wrote:

> Simen kjaeraas:
>
>> This is basically already possible in D:
>
> I suggest you to stop using the single underscore as identifier.

And I suggest you stop being bothered about example code that's
meant to illustrate a point rather than be production-ready.

-- 
Simen
March 07, 2011
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