View mode: basic / threaded / horizontal-split · Log in · Help
January 28, 2013
Re: Property discussion wrap-up
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.
January 28, 2013
Re: Property discussion wrap-up
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 ?
January 28, 2013
Re: Property discussion wrap-up
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.
January 28, 2013
Re: Property discussion wrap-up
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.
January 28, 2013
Re: Property discussion wrap-up
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
January 28, 2013
Re: Property discussion wrap-up
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
January 28, 2013
Re: Property discussion wrap-up
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 ?
January 28, 2013
Re: Property discussion wrap-up
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.
January 28, 2013
Re: Property discussion wrap-up
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
January 28, 2013
Re: Property discussion wrap-up
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
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home