Lazy eval -- an example issue

[Sean Kelly]

Walter Bright wrote:
> 
> I've struggled to get people to accept the {} version ever since D 
> adopted anonymous delegates. Haven't made much headway in getting such 
> used or in it having any sort of significant impact. How many have made 
> a "dotimes(n, exp)" function or any sort of syntax extension using it? 
> None that I've seen.

I've been working on a predicate-oriented algorithm module on and off 
for the past few weeks.  A few looping constructs have been left out 
because foreach seems a preferable solution in D, but the rest is coming 
along nicely.  About the only problem I had was inlining delegates 
passed to the functions, so the default operations are passed as structs 
with opCall defined instead.

> I hesitate to use argumentum ad verecundiam because it's a logical 
> fallacy, so you can take the following for what it's worth. Andrei and I 
> certainly have our differences of opinion. But when I disagree with him, 
> I'd better have done my homework, or I'll get cut to pieces. He thinks 
> (and he obviously convinced me) that removing the { } makes all the 
> difference.

I'll admit that doing so makes a difference to me, as it allows for 
tricks that aren't possible with explicit delegate signifiers.  But I'm 
undecided as to whether this is a "good thing" or not--I plan to give it 
some time before I decide.  I do think it's unfortunate that Kris' 
logging code will be unable to accept both string and delegate 
parameters however.  And I'd like to note that all the tricks I'm 
thinking of for the new syntax tend to involve refactoring existing code 
(which is potentially dangerous, given the issue with side-effects) 
rather than writing new code.  With new code I don't see much benefit to 
omitting all evidence that a parameter will be converted to a delegate, 
as it's something the user must be aware of to write correct code.


Sean