Lazy evaluation: Difference between revisions

From Rosetta Code
Content added Content deleted
m (English, paradigm cat)
(Moved to enc, corrected English, reorganized some facts)
 
(3 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[[Category:Encyclopedia]][[Category:Programming Paradigms]]'''Lazy evaluation''' describes a strategy of expression evaluation when the evaluation is done as late as possible. The opposite to lazy evaluation is '''eager evaluation''', when the evaluation is performed as early as possible.
<!--[[Category:Programming Paradigms]] is this a paradigm?-->[[Category:Encyclopedia]]'''Lazy evaluation''' describes a strategy of expression evaluation when the evaluation is done as late as possible. The opposite to lazy evaluation is '''eager evaluation''', when the evaluation is performed as early as possible. Constant folding is an example of eager evaluation optimization. [[Haskell]]'s handling of infinite lists is an example of lazy evaluation.


Usually the programming language do not specify laziness leaving the decision to optimization.
Usually the programming language does not specify laziness, leaving the decision to optimization.


Lazy evaluation is best represented by short-circuit logical operations, known to many programming languages.
Lazy evaluation is best represented by short-circuit logical operations, known to many programming languages.
Line 7: Line 7:
There exist two major contexts where laziness of evaluation is considered:
There exist two major contexts where laziness of evaluation is considered:


* When the expression value does not depend on the evaluation time, which is usually the case for functional programing languages. In this context lazy evaluation can be used for optimization purposes and as light-weight [[closures]]. Constants folding is an example of eager evaluation optimization.
* When the expression value does not depend on the evaluation time, which is usually the case for [[functional programming]] languages. In this context lazy evaluation can be used for optimization purposes and as light-weight [[closures]].


* When the expression value depends on the evaluation time, laziness changes the program semantics. This type of laziness is used in low-level [[concurrent programming]], when the state of an object might change asynchronously to the program. Such objects are usually marked as ''volatile'', and their values are acquired as late as possible. Further, the compiler is instructed not to store them when evaluating temporal expressions.
* When the expression value depends on the evaluation time, laziness changes the program semantics. This type of laziness is used in low-level [[concurrent programming]], when the state of an object might change asynchronously to the program. Such objects are usually marked as ''volatile'', and their values are acquired as late as possible. Further, the compiler is instructed not to store them when evaluating temporal expressions.

Latest revision as of 20:30, 17 August 2009

Lazy evaluation describes a strategy of expression evaluation when the evaluation is done as late as possible. The opposite to lazy evaluation is eager evaluation, when the evaluation is performed as early as possible. Constant folding is an example of eager evaluation optimization. Haskell's handling of infinite lists is an example of lazy evaluation.

Usually the programming language does not specify laziness, leaving the decision to optimization.

Lazy evaluation is best represented by short-circuit logical operations, known to many programming languages.

There exist two major contexts where laziness of evaluation is considered:

  • When the expression value does not depend on the evaluation time, which is usually the case for functional programming languages. In this context lazy evaluation can be used for optimization purposes and as light-weight closures.
  • When the expression value depends on the evaluation time, laziness changes the program semantics. This type of laziness is used in low-level concurrent programming, when the state of an object might change asynchronously to the program. Such objects are usually marked as volatile, and their values are acquired as late as possible. Further, the compiler is instructed not to store them when evaluating temporal expressions.