DenkzeitWiki

Lazy Evaluation

An evaluation strategy combining normal order evaluation with updating. Under normal order evaluation (outermost or call-by-name evaluation) an expression is evaluated only when its value is needed in order for the program to return (the next part of) its result. Updating means that if an expression's value is needed more than once (i.e. it is shared), the result of the first evaluation is remembered and subsequent requests for it will return the remembered value immediately without further evaluation. This is often implemented by graph reduction. An unevaluated expression is represented as a closure - a data structure containing all the information required to evaluate the expression.[1]

• streams - lazy lists (e.g. SICP)
• Lazy evaluation schemes may be constructed in Scheme using the (delay) and (force) functions. [2]

• http://lawfulsamurai.blogspot.com/2009/01/sicp-section-42-variations-on-scheme.html
  
• http://mitpress.mit.edu/sicp/full-text/sicp/book/node85.html Normal Order and **Applicative Order If the body of a procedure is entered before an argument has been evaluated we say that the procedure is non-strict in that argument. If the argument is evaluated before the body of the procedure is entered we say that the procedure is strict in that argument. In a purely applicative-order language, all procedures are strict in each argument. In a purely normal-order language, all compound procedures are non-strict in each argument, and primitive procedures may be either strict or non-strict. There are also languages (see exercise ) that give programmers detailed control over the strictness of the procedures they define.
  
• http://www.ibm.com/developerworks/linux/library/l-lazyprog.html
  
• http://www.alsonkemp.com/haskell/thinking-about-haskell-you-know-lazy-evaluation-you-just-dont-know-it/
  
• http://en.wikipedia.org/wiki/Evaluation_strategy
  
  • call-by-need
  
  
• http://homepages.inf.ed.ac.uk/wadler/topics/call-by-need.html
  • Lazy, or call-by-need, languages schedule work dynamically by building closures, and shun side effects
  
  
• http://jfkbits.blogspot.com/2008/05/call-by-need-lambda-poor-mans-macro.html
  
• http://en.wikipedia.org/wiki/Thunk
  • call-by-name, thunks

• http://codebetter.com/blogs/matthew.podwysocki/archive/2009/06/02/when-side-effects-and-laziness-collide.aspx
  • When dealing with asynchronous expressions mixed with sequence expressions can cause problems due to object lifetimes. As I’ve had in my earlier post, it’s best to avoid such scenarios if possible and instead, focus on an eager approach.
  
  
• http://weblogs.asp.net/podwysocki/archive/2008/09/12/side-effects-and-functional-programming.aspx

• A History of Haskell: Being LazyWith Class
  
• CPS 343/543 Lecture notes: Lazy evaluation and thunks

• Don't be lazy about lazy sequences. by UncleBob?