On Sunday, 27 January 2013 at 17:37:29 UTC, Dicebot wrote:
> On Sunday, 27 January 2013 at 16:50:47 UTC, deadalnix wrote:
>> Off topic rant.
>>
>> I suppressed a counterexample in the section Optional parentheses
>> - Extra note .
>>
>> The note state that some stuff are valid for *function* and the counter example showed ambiguity using opCall. I don't know who did this and I don't care. I however can't stand intellectual dishonesty.
>
> It was me, sorry if I have offended you. I tend to read "function" as "callable" if not mentioned otherwise and thus was wandering how note refers to this case. This left counter-example in hope that someone will comment it.
>
> Now I see that it should be better suited to discussion, but at that time it was just curiosity, not desire to prove anything.

OK, let me restate that, as it was probably too strong.

We got to be pedantic on the vocabulary used. We are trying to define very precise stuffs. We cannot define anything with imprecise vocabulary.

Sorry for the intellectual dishonesty part, that was too much.

On Monday, 28 January 2013 at 00:07:05 UTC, Andrei Alexandrescu wrote:
> On 1/27/13 3:22 PM, Zach the Mystic wrote:
>> Several suggestions here:
>>
>> With regard to optional parentheses, it had been suggested that any
>> ambiguity be regarded as an error. This is the example I used:
>>
>> int foo() { return 4; }
>> auto x = foo; // Error: gives 4 or gives function foo?
>>
>> I suggested the ambiguity be resolved thus:
>>
>> auto x = foo(); // parens to get the return value
>> auto y = cast(function) foo; // cast(function) gives the function
>
> I was thinking of just using &foo, like in C.
>

The &foo syntax is really not a good one.

First, it is ambiguous with function that return a reference. Secondly, it create a different behavior for variables and source code defined functions.

This is one of those cases where the omition of () cascade in more mess.

At the end, ask any dev and he/she will say you that foo is a function. Why not make foo a function ?

On Monday, 28 January 2013 at 00:07:05 UTC, Andrei Alexandrescu wrote:
> I was thinking of just using &foo, like in C.
>
> BTW also regarding optional parentheses, while I was working on https://github.com/D-Programming-Language/tools/pull/41/files I refactored a bit of code to use UFCS and paren-less syntax. I must say I find this a very fluid style of programming that I'd hate to lose.
>
> One more thought - though optional parens and properties are distinct issues, there is some interaction: optional parens reduce the need for @property annotation on read-only properties.
>
>
> Andrei

It was pointed out by Maxim Fomin that my example was wrong. The only question I had about &foo was if you're in a context where you're not even sure if foo is callable or just plain data, &foo could be silently accepted whereas cast(function) could say "Error: foo is not castable as a function", which makes it safe despite its appearance. The massive downside is simply that it's not at all concise.

I first saw UFCS and optional parentheses in Ruby and it seemed both alluring and deceptively simple. I will give you a thought in return for your thought. Reading the other people's posts who prefer always parens makes it seem that if they had to choose between a Volvo and a Ferrari, they would choose the Volvo, whereas you would choose the Ferrari. But the thing is, if the Ferrari really is a damn good car, it's the best of both worlds. Do you think the Ferrari (i.e. optional parens) has got what it needs under the hood?

Also, the single-instance struct suggestion is another possible way to eliminate @property entirely. They would all just be single instance structs with no data of their own. opGet would satisfy the sticklers by making parens downright illegal on functions which call it.

On Monday, 28 January 2013 at 00:07:05 UTC, Andrei Alexandrescu wrote:
> BTW also regarding optional parentheses, while I was working on https://github.com/D-Programming-Language/tools/pull/41/files I refactored a bit of code to use UFCS and paren-less syntax. I must say I find this a very fluid style of programming that I'd hate to lose.
>
> One more thought - though optional parens and properties are distinct issues, there is some interaction: optional parens reduce the need for @property annotation on read-only properties.
>
>
> Andrei

I'm sorry for answering twice, but I think I understand something that I didn't before. I was taking it as a _given_ that optional parentheses are here to stay. I was only proposing that the compiler give an error when it has two valid choices which both compile legally. I'm pretty sure actual cases where you are forced to use either "()" or "cast(function)" are going to be rare. In most cases, only one version of the code will actually compile. Another consideration is that testing for all these cases may increase compilation time, whereas silently giving one type priority over the other will not.

On 1/27/13 9:16 PM, deadalnix wrote:
> On Monday, 28 January 2013 at 00:07:05 UTC, Andrei Alexandrescu wrote:
>> On 1/27/13 3:22 PM, Zach the Mystic wrote:
>>> Several suggestions here:
>>>
>>> With regard to optional parentheses, it had been suggested that any
>>> ambiguity be regarded as an error. This is the example I used:
>>>
>>> int foo() { return 4; }
>>> auto x = foo; // Error: gives 4 or gives function foo?
>>>
>>> I suggested the ambiguity be resolved thus:
>>>
>>> auto x = foo(); // parens to get the return value
>>> auto y = cast(function) foo; // cast(function) gives the function
>>
>> I was thinking of just using &foo, like in C.
>>
>
> The &foo syntax is really not a good one.
>
> First, it is ambiguous with function that return a reference.

To get the address of a function's result: &fun().

> Secondly,
> it create a different behavior for variables and source code defined
> functions.

I'm not convinced that's a bad thing. I've come to realize functions and variables _are_ different.

> This is one of those cases where the omition of () cascade in more mess.

I disagree.

> At the end, ask any dev and he/she will say you that foo is a function.
> Why not make foo a function ?

The pros and cons have been hashed many times, I'm not sure I have much to add.


Andrei

On 1/27/13 9:25 PM, Zach the Mystic wrote:
> I first saw UFCS and optional parentheses in Ruby and it seemed both
> alluring and deceptively simple. I will give you a thought in return for
> your thought. Reading the other people's posts who prefer always parens
> makes it seem that if they had to choose between a Volvo and a Ferrari,
> they would choose the Volvo, whereas you would choose the Ferrari. But
> the thing is, if the Ferrari really is a damn good car, it's the best of
> both worlds. Do you think the Ferrari (i.e. optional parens) has got
> what it needs under the hood?

I'm not sure I understand the question.

> Also, the single-instance struct suggestion is another possible way to
> eliminate @property entirely. They would all just be single instance
> structs with no data of their own. opGet would satisfy the sticklers by
> making parens downright illegal on functions which call it.

An idiom is a possible option.


Andrei

On Monday, 28 January 2013 at 04:40:34 UTC, Andrei Alexandrescu wrote:
> To get the address of a function's result: &fun().
>

That is kind of the point, fun is equivalent to fun(), but &fun is not equivalent to &fun(), not equivalent to (&fun)(), which is weird.

> I'm not convinced that's a bad thing. I've come to realize functions and variables _are_ different.
>

Can you elaborate on that ?

On Monday, 28 January 2013 at 04:42:34 UTC, Andrei Alexandrescu wrote:
>>  Do you think the Ferrari (i.e. optional parens) has got
>> what it needs under the hood?
>
> I'm not sure I understand the question.

Just that the elegant appearance of UFCS and optional parens isn't offset underneath by built-in ambiguities which lead to problems either with compiling wrongly or with making the code difficult to read. I don't really need an answer.

On Monday, 28 January 2013 at 04:40:34 UTC, Andrei Alexandrescu wrote:
> I'm not convinced that's a bad thing. I've come to realize functions and variables _are_ different.

The behavior of the variable seems to be a subset of what the function does, i.e., they are both the exact same thing except a function does not have a fixed implied implementation or a fixed implied data store, and the variable is the smallest reducible abstraction layer - provided that you do not dig any deeper into the machine code implementation.

I think the reason why removal of empty paren's enjoys a level of favor, is because it removes a difference between a variable and a function that serves only an artificial purpose instead of a real one, thus removal is more of a relief than a burden.

The edge case breakages happen where the assumed differences between function and variable were depended on, so resolving edge case problems really should be done at the high level rather than at the low level otherwise we're not really fixing anything, we're just shifting the complexity around, removing it from one level and piling it back on at another level.

--rt

On Monday, 28 January 2013 at 07:17:56 UTC, Rob T wrote:
> On Monday, 28 January 2013 at 04:40:34 UTC, Andrei Alexandrescu wrote:
>> I'm not convinced that's a bad thing. I've come to realize functions and variables _are_ different.
>
> The behavior of the variable seems to be a subset of what the function does, i.e., they are both the exact same thing except a function does not have a fixed implied implementation or a fixed implied data store, and the variable is the smallest reducible abstraction layer - provided that you do not dig any deeper into the machine code implementation.

Variables and functions behaves very differently in storage, access, side effects, aliasing and many other criteria. Functions actually have fixed implementation as a part of executable/object file. Besides, D, as a system programming language, has limited opportunities to avoid low-level issues. The problem is that often there is need for some intermediate solution when only variable (only function) is not a satisfactory decision.

> I think the reason why removal of empty paren's enjoys a level of favor, is because it removes a difference between a variable and a function that serves only an artificial purpose instead of a real one, thus removal is more of a relief than a burden.
>
> The edge case breakages happen where the assumed differences between function and variable were depended on, so resolving edge case problems really should be done at the high level rather than at the low level otherwise we're not really fixing anything, we're just shifting the complexity around, removing it from one level and piling it back on at another level.
>
> --rt