lazy redux

[Andrei Alexandrescu]

Tim Matthews wrote:
> Andrei Alexandrescu wrote:
>> Should we sack lazy? I'd like it to have a reasonable replacement. 
>> Ideas are welcome!
>>
>> Andrei
> 
> According to the doc page: 
> http://www.digitalmars.com/d/2.0/lazy-evaluation.html
> you (and/or Tomasz Stachowiak) were the one who suggested it in the 
> first place. How'd it go for you? :)

Well the story is, I suggested something very different, namely 
automatic conversion of expressions to delegates, i.e.:

void fun(int delegate() dg) { ... }

int a;
fun(a += 5); // works, same as fun({ a += 5; });

I am not sure about how good that idea is, but anyway on top of it 
Tomasz suggested defining a storage class for that, which (1) takes 
matters to a completely place, (2) marks a sharp decline in the quality 
of the feature. I protested the addition of "lazy" very strongly in a 
subsequent post. Since I was relatively new in the newsgroup and the 
rant bordered on an ad hominem attack against Tomasz, it earned me a 
good amount of negative goodwill (and for good reasons). If I remember 
correctly, the flamewar that ensued in my leaving the newsgroup for a 
good while. I'm very glad the atmosphere has improved so much since - 
back then it was often some sort of a turf war.

Anyhow, if we leave the feature as an implicit conversion expression -> 
delegate or function, I think the whole thing is sound (contingent on 
probably taking care of a couple of corner cases). The remaining problem 
is that fun(gun()) does not always evaluate gun(), even though the 
reader who is unaware or forgot about the conversion thinks otherwise. 
If we require fun({gun();}), the notation is more awkward but also 
clarifies to the reader what's happening.

My take is this: since assert() establishes a precedent, I'd hate that 
to be magic inaccessible to mere mortals. Functions like enforce() and 
logging frameworks can make good use of the feature.

> In haskell land they love lazy evaluation. Lazy evaluation can have many 
> advantages but depending on the situation can be wrote using alternates 
> that d provides:
> 
> mixins -- allows turning a string into expression at a later time
> delegates -- only called when used explicitly
> logical ('&&' and '||') operators already only evaluate what is needed
> 
> If it stays though I would prefer a different syntax so where we already 
> have:
> 
> char[] delegate() dg
> char[] function() fp
> 
> then something like this would be more consistent and intuitive:
> 
> char[] expression exp
> 
> rather than the current:
> 
> lazy char[] exp

I think defining a new type is a lot of work, even more work than "lazy" 
itself which is just a storage class.


Andrei