www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - reddit - lazy evaluation of function arguments

reply Walter Bright <newshound1 digitalmars.com> writes:
vote up!

http://www.reddit.com/info/6pkri/comments/
Jun 30 2008
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
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
Jun 30 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Lars Ivar Igesund wrote:
 a ploy to move people to 2.0? :)

My plan is stunning in it's exhibition of pure eeevil.
Jun 30 2008
prev sibling next sibling parent reply Georg Wrede <georg nospam.org> writes:
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. :-(
Jun 30 2008
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
== 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
Jun 30 2008
prev sibling parent "Manfred_Nowak" <svv1999 hotmail.com> writes:
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
Jul 01 2008
prev sibling parent reply renoX <renosky free.fr> writes:
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
Jul 12 2008
parent Matthias Walter <Matthias.Walter st.ovgu.de> writes:
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
Jul 13 2008