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