On Sunday, 20 May 2012 at 18:22:16 UTC, F i L wrote:
> On Saturday, 19 May 2012 at 23:03:50 UTC, Walter Bright wrote:
>> http://www.reddit.com/r/programming/comments/tui75/lazy_evaluation_of_function_arguments_in_d/
>
> Didn't know this was new. Stumbled upon it a day-or-so ago and (while searching for something else) and thought it was a cool little "hidden gem" of dlang.org
>
> Guess I just got and early showing ;)

I saw it earlier, too.

Le 20/05/2012 17:59, David Nadlinger a écrit :
> On Sunday, 20 May 2012 at 15:41:05 UTC, deadalnix wrote:
>> If so, this isn't complicated, just do some rewrite magic on the
>> expression if it is given and expression where a delegate is expected.
>
> Lazy parameters once used to work like this (back in the D1 times,
> before there even was a »lazy« storage class), but not everybody was
> happy with it – among other discussions, you should be able to find a
> thread named something along the lines of »But I don't want my delegates
> to be lazy« in the NG archives.
>
> David

Thank for the information. I think this thread have some good point but :
1/ Nobody is even considering pure/nothrow/@safe .
2/ Many problems are not solved with lazy.

lazy in itself isn't bad, but it don't play well with other features of the language.

A language that have many feature that don't integrate nicely with one another already exists. It is called C++, it is a reason that lead to D. We can do the same mistake again and again, but it seems that E already exists.

On Sunday, 20 May 2012 at 18:59:22 UTC, deadalnix wrote:
> Le 20/05/2012 17:59, David Nadlinger a écrit :
>> On Sunday, 20 May 2012 at 15:41:05 UTC, deadalnix wrote:
>>> If so, this isn't complicated, just do some rewrite magic on the
>>> expression if it is given and expression where a delegate is expected.
>>
>> Lazy parameters once used to work like this (back in the D1 times,
>> before there even was a »lazy« storage class), but not everybody was
>> happy with it – among other discussions, you should be able to find a
>> thread named something along the lines of »But I don't want my delegates
>> to be lazy« in the NG archives.
>>
>> David
>
> Thank for the information. I think this thread have some good point but :
> 1/ Nobody is even considering pure/nothrow/@safe .
> 2/ Many problems are not solved with lazy.
>
> lazy in itself isn't bad, but it don't play well with other features of the language.
>
> A language that have many feature that don't integrate nicely with one another already exists. It is called C++, it is a reason that lead to D. We can do the same mistake again and again, but it seems that E already exists.

I rather agree. However, if the language doesn't provide some feature it doesn't mean there is no way to accomplish the task. I would be interested to know how to do it.

On Sunday, 20 May 2012 at 18:59:22 UTC, deadalnix wrote:
> Le 20/05/2012 17:59, David Nadlinger a écrit :
>> On Sunday, 20 May 2012 at 15:41:05 UTC, deadalnix wrote:
>>> If so, this isn't complicated, just do some rewrite magic on the
>>> expression if it is given and expression where a delegate is expected.
>>
>> Lazy parameters once used to work like this (back in the D1 times,
>> before there even was a »lazy« storage class), but not everybody was
>> happy with it – among other discussions, you should be able to find a
>> thread named something along the lines of »But I don't want my delegates
>> to be lazy« in the NG archives.
>>
>> David
>
> Thank for the information. I think this thread have some good point but :
> 1/ Nobody is even considering pure/nothrow/@safe .
> 2/ Many problems are not solved with lazy.
>
> lazy in itself isn't bad, but it don't play well with other features of the language.
>
> A language that have many feature that don't integrate nicely with one another already exists. It is called C++, it is a reason that lead to D. We can do the same mistake again and again, but it seems that E already exists.

I rather agree. However, if the language doesn't provide some
feature it doesn't mean there is no way to accomplish the task. I
would be interested to know how to do it.

On Sunday, 20 May 2012 at 00:26:14 UTC, Mehrdad wrote:
> http://www.reddit.com/r/programming/comments/tui75/lazy_evaluation_of_function_arguments_in_d/c4pwvyp
>
> +1 ^

+1 too:

'f(x++)' what's the value of x after executing this function call?

If f is a function with a normal argument, the new value is x + 1, if f is a function with a lazy argument, the new value can be anything (depends on how many time the expression is evaluated).

So the lazy keyword hurts maintainability: you need an IDE which color differently the callsite to be usable, really ugly..

How about improving 'f({ return x ++ })' to either f({^x++})' (^ is return in Smalltalk) or 'f({x++})'?

On 05/21/2012 11:07 AM, renoX wrote:
> On Sunday, 20 May 2012 at 00:26:14 UTC, Mehrdad wrote:
>> http://www.reddit.com/r/programming/comments/tui75/lazy_evaluation_of_function_arguments_in_d/c4pwvyp
>>
>>
>> +1 ^
>
> +1 too:
>
> 'f(x++)' what's the value of x after executing this function call?
>
> If f is a function with a normal argument, the new value is x + 1, if f
> is a function with a lazy argument, the new value can be anything
> (depends on how many time the expression is evaluated).
>

int x;

void f(int){x=anything;}

void main(){ f(x++); }


> So the lazy keyword hurts maintainability:
> you need an IDE which color differently the callsite to be usable, really ugly..
>

Have you actually encountered this problem in practice?

> How about improving 'f({ return x ++ })' to either f({^x++})' (^ is
> return in Smalltalk) or 'f({x++})'?
>

f(()=>x++) is already short enough.

I either think lazy should remain as it is, or that delegate syntax should be explicit.  But if delegate syntax is explicit, »lazy« isn't needed anymore.  The whole point of it is to have nice syntax at the call site.  Delegate syntax is, however, conscise enough already.

Bugs due to lazy might happen, although its use is extremely rare anyway.

I'm not sure what to say about "i" versus "i()" when using lazy parameter "i" in a function.  I'm leaning towards explicit "i()" (DMD allows both on my machine), because just using "i" is kind of misleading.  EXCEPT if using plain "i" would only evaluate the expression once, and "i()" for every time we use it.  (And only one notation would be permitted per function).

(This obviously doesn't change any confusion from the call site.)

What do you think?

> The whole point of it is to have nice syntax at the call site.  Delegate syntax is, however, conscise enough already.

I agree with that completely. I have also never used lazy, nor have I seen it used in a public API.

On 5/21/12 8:48 AM, jerro wrote:
>> The whole point of it is to have nice syntax at the call site.
>> Delegate syntax is, however, conscise enough already.
>
> I agree with that completely. I have also never used lazy, nor have I
> seen it used in a public API.

enforce() uses lazy.

Andrei

On Monday, 21 May 2012 at 14:26:31 UTC, Andrei Alexandrescu wrote:
> On 5/21/12 8:48 AM, jerro wrote:
>>> The whole point of it is to have nice syntax at the call site.
>>> Delegate syntax is, however, conscise enough already.
>>
>> I agree with that completely. I have also never used lazy, nor have I
>> seen it used in a public API.
>
> enforce() uses lazy.

So will absolutePath() and relativePath(), starting next release:

https://github.com/D-Programming-Language/phobos/pull/522

-Lars