http://www.reddit.com/r/programming/comments/tui75/lazy_evaluation_of_function_arguments_in_d/

http://www.reddit.com/r/programming/comments/tui75/lazy_evaluation_of_function_arguments_in_d/c4pwvyp

+1 ^

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 ^


>Yeah, I'd like both "lazy" and "ref" to be forced to be used from the call site >and not just in the declaration. I don't use lazy that often but I would use >'ref' more often if I could tell from the call site that my arguments might be >modified.
IMO requiring caller to specify ref, out or lazy would make D programs more robust and easier to understand. And it is clearly much easier, than, for example, would be repeating pure, nothrow, safe, or even contracts at each call (any of these would not make sence for me because they are enforced by the compiler).

Sorry if the above is confusing, I have difficulties to explain it more clearly.

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/

Lazy evaluation has been discussed previously, but this topic is important and the problems have not been solved yet.

Functional languages, like Haskel, Scala or F#, have the semantics of lazy evaluation which is to evaluate things at most once. Evaluating many times is accomplished via a function or delegate.

Thus lazy in D is (IMO):
* confusing, because it doesn't take into account lazy semantics
* close to useless, because functions or delegates could do the same job and not confuse the users
* somehow hiding the need to have the functionality of evaluating an expression at most once. For example, I need this to work with immutable data, but it is not possible conceptually at this moment (clearly, evaluating and storing the result would mutate the data). I understand that designing this would mean there is the need for synchronization for immutable data. But at least this functionality could exist for pure functions.

Le 20/05/2012 01:03, Walter Bright a écrit :
> http://www.reddit.com/r/programming/comments/tui75/lazy_evaluation_of_function_arguments_in_d/
>

This feature break pure/@safe/nothrow .

I don't think this is a good idea to promote it right now, as it WILL have to change.

On 05/20/2012 04:09 PM, deadalnix wrote:
> Le 20/05/2012 01:03, Walter Bright a écrit :
>> http://www.reddit.com/r/programming/comments/tui75/lazy_evaluation_of_function_arguments_in_d/
>>
>>
>
> This feature break pure/@safe/nothrow .
>

It does not break them.

lazy currently makes it impossible to have some guarantees that might be desirable to have inside the function with the lazy parameter, but the call site has all the information needed in order to establish them again.

> I don't think this is a good idea to promote it right now, as it WILL
> have to change.

Le 20/05/2012 16:17, Timon Gehr a écrit :
> On 05/20/2012 04:09 PM, deadalnix wrote:
>> Le 20/05/2012 01:03, Walter Bright a écrit :
>>> http://www.reddit.com/r/programming/comments/tui75/lazy_evaluation_of_function_arguments_in_d/
>>>
>>>
>>>
>>
>> This feature break pure/@safe/nothrow .
>>
>
> It does not break them.
>
> lazy currently makes it impossible to have some guarantees that might be
> desirable to have inside the function with the lazy parameter, but the
> call site has all the information needed in order to establish them again.
>

How would you create a nothrow function with a lazy parameter ?

This will depend both on the callee and the caller, for instance :

nothrow void foo(lazy int i) {
    try {
        // Do something with i.
    } catch(Exception e) {}
}

This function is nothrow even if the parameter isn't. Without the try catch, the function can be nothrow depending on what is passed as argument.

The article state that the whole point is : « The only trouble is that few are going to want to wrap expressions with { return exp; }. »

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 prevent expressing the attribute needed. And extending lazy would ends up to the point where you remove the delegate keyword and replace it with lazy.

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

On Sunday, 20 May 2012 at 14:02:52 UTC, deadalnix wrote:
> Le 20/05/2012 01:03, Walter Bright a écrit :
>> http://www.reddit.com/r/programming/comments/tui75/lazy_evaluation_of_function_arguments_in_d/
>>
>
> This feature break pure/@safe/nothrow .
>
> I don't think this is a good idea to promote it right now, as it WILL have to change.

What I would like is to have community agree on the topic, not necessarily change anything. Agreement would mean that the issues are either fixed, or some workaround proposed, or it is stated that this is impossible to have due to some other design decision, or not important for some reason.

For me the most important would be to understand how to implement functionality "evaluate expression at most once and store result for subsequent calls", even if this would be restricted to pure nothrow. And if we claim that immutabilily is the advantage of D, IMO, we need to be able to have lazy evaluation possible for immutable data structures. (AFAIK, Haskell has immutability and lazy evaluation by default.) But I don't know how to avoid synchronization for both evaluating and storing the result.

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 ;)