Talk:Lazy evaluation

message: I have a function in haskell, which can sort infinite lists. Of course it takes an infinite time, but it shows the power of lazy evaluation:
import Data.List
import System.Random
import Control.Monad
sortingStream :: (Ord a) => [a] -> a
sortingStream = tail . iterate ss
showss r n = print $ take 30 $ sortingStream r !! n
main = do
        s <- newStdGen :: IO StdGen
        let r = randomRs (1,100000) s :: [Int]
        forM_ [0..] (showss r)
ss :: (Ord a) => [a] -> [a]
ss [] = []
ss [x] = [x]
ss [x,y]    | x <= y = [x,y]
            | otherwise = [y,x]
ss (x:y:xs) | x <= y  =  x: ss (y:xs)
            | otherwise =  y: ss (x:xs)
Would it be interesting to add? Or is it too long and not relevant?
Edgar Klerks  —Preceding unsigned comment added by 195.241.100.248 (talk) 13:02, 24 June 2010 (UTC)
thread_title: Demonstration of lazy evaluation

message: I think the "lazy evaluation as design pattern" section is misguided.  This kind of pattern is usually called either "event-driven" or "reactive" (depending on the community you're a part of).  This design pattern is fundamentally based on a push model, where changes are actively propagated to their dependents, rather than the pull model that lazy evaluation uses.
Kimbly 16:46, 7 January 2006 (UTC)
replies: text: I also think it's misleading to talk about design patterns (which are ad hoc techniques that programmers adopt when they are using languages that are inadequate to express the abstractions they need to express) in an article about lazy evaluation, which is a programming language design construct that is backed up with formal semantics. Perhaps it would be best to merge this section into Design patterns, and add a note about the "lazy evaluation as design pattern" idea under "See also" or such. Catamorphism 19:18, 7 January 2006 (UTC)
replies: text: The terms "lazy evaluation" and "design pattern" are both very loaded words in certain parts of CS; the section on "lazy evaluation as a design pattern" doesn't even describe a design pattern as described in that article.  The idea that section was trying to express seems to be well-covered in "minimal evaluation", which is already linked. --bmills 04:56, 8 January 2006 (UTC)
thread_title: Lazy evaluation as a design pattern

message: I'm not sure I'm completely qualified to write it, but this page should probably mention terms like "call by need", and "leftmost outermost evaluation".  The latter tends term is used when describing lazy evaluation in the context of lambda calculus, so a brief section (or at least a link) to LC would be useful.
Kimbly 19:36, 14 January 2006 (UTC)
replies: text: Evaluation strategy covers the call-by-need/call-by-name distinction, so I added a paragraph linking to that. Catamorphism 21:10, 14 January 2006 (UTC)

text: I also edited Evaluation strategy to mention the terms "leftmost outermost" and "leftmost innermost". Catamorphism 21:25, 14 January 2006 (UTC)
thread_title: Evaluation strategies

message: The article is really fuzzy with respect to actually defining lazy evaluation (probably in part because lazy programming literature tends to be a bit vague).  The article explains what lazy evaluation does, but not what it is.  Does lazy evaluation encompass all non-strict evaluation strategies?  What about parallel call-by-need, which maximizes (rather than minimizes) the amount of computation performed?  Similarly, delayed evaluation is also left undefined.  —donhalcon╤ 04:19, 7 March 2006 (UTC)
thread_title: Fuzziness

message: From the research that I've done lazy evaluation refers to how expressions are evaluated when they are passed as arguments to functions and entails the following three points:
#The expression is only evaluated if the result is required by the calling function.
#The expression is only evaluated to the extend that is required by the calling function.
#the expression is never evaluated more than once. 
: The article seems to be erroneous here. Following David A. Schmidt, "Denotational Semantics", p.181: Delayed evaluation is the first item above. The third item is in David A. Watt, "Programming Language concepts and Paradigms", p. 100, called applicative-order evaluation or eager evaluation; the opposite is called normal-order evaluation. Adding the two last items gives lazy evaluation. Call-by-need evaluation requires full evaluation once it has been started.Haberg 09:29, 17 October 2007 (UTC)
thread_title: Narrower Definition

message: I think these are sufficiently distinct concepts that they ought to live in separate articles. --Saforrest 02:31, 14 April 2007 (UTC)
replies: text: Since it's been over a month since the previous comment, I removed the tag. Nibios 15:16, 9 November 2007 (UTC)
thread_title:  Should not be merged with delay 

message: The (pseudo?)code and its explanation are unclear; a plain-language interpretation of the code block would be helpful. chrylis (talk) 21:13, 20 February 2009 (UTC)
thread_title:  Control structures 

message: According to the intro, "lazy evaluation" and "delayed evaluation" are synonymous. In that case, there shouldn't be a separate section on the latter; otherwise, there needs to be a clearer distinction between the two. Danielx (talk) 17:07, 28 April 2009 (UTC)
thread_title:  Let's get rid of the "Delayed evaluation" section 

message: This article contains several huge mistakes. E.g. lazy evaluation is usually defined as normal-order (or non-strict) evaluation with sharing of common expressions. The article claims it is applicative-order evaluation, the exact opposite. —Ruud 22:16, 22 January 2011 (UTC)
thread_title:  Fundamentally flawed 

message: Hello fellow Wikipedians,
I have just added archive links to  on Lazy evaluation. Please take a moment to review my edit. If necessary, add  after the link to keep me from modifying it. Alternatively, you can add  to keep me off the page altogether. I made the following changes:
*Added archive http://web.archive.org/web/20061110034450/http://nemerle.org:80/Lazy_evaluation to http://nemerle.org/Lazy_evaluation
When you have finished reviewing my changes, please set the checked parameter below to true to let others know.
Cheers.—cyberbot IITalk to my owner:Online 11:30, 27 February 2016 (UTC)
thread_title:  External links modified 

message: I have added a brief demonstration for simulating laziness in JavaScript (it is somewhat equivalent to a transpilation of a Haskell implementation using Control.Monad.Memo.Vector.Unsafe). I suggest, in the context of this article, it would benefit the reader if the demonstrations for other languages would also be expressed as brief demonstrations; not tutorials including details such as version differences, syntactic sugar, alternative approaches, or other notes. 85.255.233.198 (talk) 09:37, 21 February 2021 (UTC)
thread_title:  Simulating laziness in eager languages