www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How does laziness and UFCS interact?

reply "Logan Capaldo" <logancapaldo gmail.com> writes:
I just became aware of 

but it seems non-obvious to me how lazy + UFCS should work in 
general.

consider


void lazily(T)(lazy T expression)
{
    expression();
}

It's clear when saying lazily(a.b().c()); that the whole of 
"a.b().c()" is going to be evaluated lazily. With UFCS though, 
I'm more unsure:

is a.b().c().lazily() -> lazily(a.b().c()) or is it more akin to

auto tmp = a.b();
lazily(tmp.c());

If the later is it possible to force the former while still using 
UFCS, ie is (a.b().c()).lazily() different than 
a.b().c().lazily()?
Mar 09 2015
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 03/09/2015 03:03 PM, Logan Capaldo wrote:

 I just became aware of

 seems non-obvious to me how lazy + UFCS should work in general.

 consider


 void lazily(T)(lazy T expression)
 {
     expression();
 }

 It's clear when saying lazily(a.b().c()); that the whole of "a.b().c()"
 is going to be evaluated lazily. With UFCS though, I'm more unsure:

 is a.b().c().lazily() -> lazily(a.b().c()) or is it more akin to

 auto tmp = a.b();
 lazily(tmp.c());

 If the later is it possible to force the former while still using UFCS,
 ie is (a.b().c()).lazily() different than a.b().c().lazily()?


You are right. I had the same observation at minute 11:27 below, where I 
warn against UFCS with assumeWontThrow:

 
http://www.youtube.com/watch?feature=player_detailpage&v=oF8K4-bieaw#t=687

Ali
Mar 09 2015
parent reply "Logan Capaldo" <logancapaldo gmail.com> writes:
On Monday, 9 March 2015 at 22:15:43 UTC, Ali Çehreli wrote:

 You are right. I had the same observation at minute 11:27 
 below, where I warn against UFCS with assumeWontThrow:


 http://www.youtube.com/watch?feature=player_detailpage&v=oF8K4-bieaw#t=687

 Ali


Sorry, which is right? I know ifThrown is lazy, I'm curious about 
the "amount" of the expression that is evaluated lazily.


   a.b().c().assumeWontThrow     vs.  a.b().c().assumeWontThrow
   ^--+----^                                ^-^
      |                                      |
      +- lazy?                               +- lazy?


The video seems to say "don't use lazy functions with UFCS 
because you might think the lazy part gets evaluated first, when 
it does not". Seems reasonable, although I don't know it's any 
different than assumeWontThrow(f()).
Mar 10 2015
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 10 March 2015 at 14:41:00 UTC, Logan Capaldo wrote:

 On Monday, 9 March 2015 at 22:15:43 UTC, Ali Çehreli wrote:

 You are right. I had the same observation at minute 11:27 
 below, where I warn against UFCS with assumeWontThrow:


 http://www.youtube.com/watch?feature=player_detailpage&v=oF8K4-bieaw#t=687

 Ali


 Sorry, which is right? I know ifThrown is lazy, I'm curious 
 about the "amount" of the expression that is evaluated lazily.


   a.b().c().assumeWontThrow     vs.  a.b().c().assumeWontThrow
   ^--+----^                                ^-^
      |                                      |
      +- lazy?                               +- lazy?


 The video seems to say "don't use lazy functions with UFCS 
 because you might think the lazy part gets evaluated first, 
 when it does not". Seems reasonable, although I don't know it's 
 any different than assumeWontThrow(f()).


a.b().c().assumeWontThrow is rewritten as 
assumeWontThrow(a.b().c()) and therefore the whole chain is lazy.
Mar 10 2015
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 03/10/2015 08:00 AM, John Colvin wrote:


 On Tuesday, 10 March 2015 at 14:41:00 UTC, Logan Capaldo wrote:

 On Monday, 9 March 2015 at 22:15:43 UTC, Ali Çehreli wrote:

 You are right. I had the same observation at minute 11:27 below,
 where I warn against UFCS with assumeWontThrow:


 






http://www.youtube.com/watch?feature=player_detailpage&v=oF8K4-bieaw#t=687

 Ali


 Sorry, which is right?




You are right that it is confusing. :)


 I know ifThrown is lazy, I'm curious about the
 "amount" of the expression that is evaluated lazily.


   a.b().c().assumeWontThrow     vs.  a.b().c().assumeWontThrow
   ^--+----^                                ^-^
      |                                      |
      +- lazy?                               +- lazy?




As John Colvin said, the first one is right. A test:

import std.stdio;

struct S
{}

S a(S s)
{
     writeln("entered a");
     return s;
}

S b(S s)
{
     writeln("entered b");
     return s;
}

void lazily(T)(lazy T expression)
{
     writeln("entered lazily");
     expression();
}

void main()
{
     S().a.b.lazily;
}

Outputs

entered lazily
entered a
entered b



 The video seems to say "don't use lazy functions with UFCS because you
 might think the lazy part gets evaluated first, when it does not".
 Seems reasonable, although I don't know it's any different than
 assumeWontThrow(f()).




You are right again. :) However, putting the lazy-taking function 
"outside" the whole expression makes it visible right away, making easy 
for me to realize that the execution order may be different from common 
chains.

Ali
Mar 10 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 10 March 2015 at 17:42:37 UTC, Ali Çehreli wrote:

 You are right again. :) However, putting the lazy-taking 
 function "outside" the whole expression makes it visible right 
 away, making easy for me to realize that the execution order 
 may be different from common chains.


"lazy" aka "named parameters" semantically works just like macros 
using textual substitution. Just imagine that it is inlined in 
situ and it becomes clear what is happening.

I believe it was the common parameter transfer mode in Algol, but 
programmers found it terribly confusing, so just about all 
languages that followed have avoided it. So if anyone gets 
confused, then find some comfort in knowing that people found it 
confusing 50 years ago too. :^)
Mar 10 2015