vote up!

http://www.reddit.com/info/6pkri/comments/

Walter Bright wrote:

> vote up!
> 
> http://www.reddit.com/info/6pkri/comments/

Voted - but most (if not all?) of this article really pertains to D 1.0
too - a ploy to move people to 2.0? :)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Lars Ivar Igesund wrote:
> a ploy to move people to 2.0? :)


My plan is stunning in it's exhibition of pure eeevil.

Walter Bright wrote:

> http://www.reddit.com/info/6pkri/comments/

...

http://www.digitalmars.com/d/2.0/lazy-evaluation.html


Hmm. I guess I should've kept a log of all my original suggestions... :-)


Incidentally, the first few examples and cases are not all too convincing (not too much reduction in code lines or complexity), which is why I guess a lot of readers quit before the end, where there actually is one compelling example. And probably a number of readers (who aren't familiar and used to lazy evaluation somewhere else)
are left with the thought that it isn't all too good for other than precisely the last example.

But I can't figure out how to improve the page either. :-(

== Quote from Georg Wrede (georg@nospam.org)'s article
> Walter Bright wrote:
> > http://www.reddit.com/info/6pkri/comments/
> ...
> http://www.digitalmars.com/d/2.0/lazy-evaluation.html
> Hmm. I guess I should've kept a log of all my original suggestions... :-)
> Incidentally, the first few examples and cases are not all too
> convincing (not too much reduction in code lines or complexity), which
> is why I guess a lot of readers quit before the end, where there
> actually is one compelling example. And probably a number of readers
> (who aren't familiar and used to lazy evaluation somewhere else)
> are left with the thought that it isn't all too good for other than
> precisely the last example.
> But I can't figure out how to improve the page either. :-(

The most compelling use of lazy functions I've found is for logging purposes--you only pay for the computation when the proper log level is activated.  The Tango logging package makes extensive use of them for this reason.


Sean

Georg Wrede wrote:

> (not too much reduction in code lines or complexity)

For me it is not a main goal to have few lines to read.
Often I found myself entangled in analyzing some code that turned out
to be of minor priority because it only guarded the main aspect of the
code from unusual cases. Putting those guards texually behind the main
aspect of the code seems canonical, because it supports my way of
turning to the main aspect first.

So I tried to use the deferring capability of lazy parameters for annotating and beautifying this common pattern, but it turned out that the extra three lines are still too distracting.


        guarded( // the guards are actually evaluated here
{
    writefln( "This is the guarded part of the code.");
    writefln( "It is not executed if one of the boolean");
    writefln( "guards encounters that its expression");
    writefln( "evaluates to true.");
}
        (), // list of guards:
        guard( false, writefln( "this is the always failing guard.")),
        guard( i==42, writefln( "this is a hitchhiking guard."))
        );


-manfred

Walter Bright a écrit :
> vote up!
> 
> http://www.reddit.com/info/6pkri/comments/

There's a drawback with "invisible" laziness: now you cannot know looking at f(<expression>) how many times <expression> may be evaluated without looking at f definition (is-it taking a 'normal' argument or a 'lazy' one).

With f({return <expression>;}) at least you know that you're sending a piece of code with may be evaluated many times, not only once..

So from a semantic POV it's clearer, from a syntactic POV, it's ugly: especially the 'return', so taking an idea from Smalltalk if you change 'return' to '^', it becomes more visually pleasant:
f({^<expression>;});
the 'syntactic' noise compared to f(<expression>); is bearable I think.

If the compiler is able to distinguish <expression> with or without side-effect then f(<expression>); could be allowed as a shortcut for f({^<expression>;}); if the <expression> is side-effect free (after all the distinction only matters where there could be side-effects)..


Sure some may ask why not allow simply f({<expression>;}); with the last expression evaluated being the return value?
A study for the E-language has shown that this leads sometimes to value being returned where they shouldn't so it's a bad idea from maintainability view and security (if the object leaked is a capability..).

Thoughts?

renoX

renoX Wrote:

> Walter Bright a écrit :
> > vote up!
> > 
> > http://www.reddit.com/info/6pkri/comments/
> 
> There's a drawback with "invisible" laziness: now you cannot know looking at f(<expression>) how many times <expression> may be evaluated without looking at f definition (is-it taking a 'normal' argument or a 'lazy' one).
> 
> With f({return <expression>;}) at least you know that you're sending a piece of code with may be evaluated many times, not only once..
> 
> So from a semantic POV it's clearer, from a syntactic POV, it's ugly:
> especially the 'return', so taking an idea from Smalltalk if you change
> 'return' to '^', it becomes more visually pleasant:
> f({^<expression>;});
> the 'syntactic' noise compared to f(<expression>); is bearable I think.
> 
> If the compiler is able to distinguish <expression> with or without side-effect then f(<expression>); could be allowed as a shortcut for f({^<expression>;}); if the <expression> is side-effect free (after all the distinction only matters where there could be side-effects)..

What about f (lazy <expression>) - the caller is forced to either put a real delegate there or a "lazy" prefix before an expression. This is also much clearer than braces, ^ or some other symbol... just an idea :)

best regards
Matthias Walter