Book contents
- Frontmatter
- Contents
- Preface
- Part I Judgments and Rules
- Part II Statics and Dynamics
- Part III Function Types
- Part IV Finite Data Types
- Part V Infinite Data Types
- Part VI Dynamic Types
- Part VII Variable Types
- Part VIII Subtyping
- Part IX Classes and Methods
- Part X Exceptions and Continuations
- Part XI Types and Propositions
- Part XII Symbols
- Part XIII State
- Part XIV Laziness
- 37 Lazy Evaluation
- 38 Polarization
- Part XV Parallelism
- Part XVI Concurrency
- Part XVII Modularity
- Part XVIII Equational Reasoning
- Part XIX Appendix
- Bibliography
- Index
37 - Lazy Evaluation
from Part XIV - Laziness
Published online by Cambridge University Press: 05 February 2013
- Frontmatter
- Contents
- Preface
- Part I Judgments and Rules
- Part II Statics and Dynamics
- Part III Function Types
- Part IV Finite Data Types
- Part V Infinite Data Types
- Part VI Dynamic Types
- Part VII Variable Types
- Part VIII Subtyping
- Part IX Classes and Methods
- Part X Exceptions and Continuations
- Part XI Types and Propositions
- Part XII Symbols
- Part XIII State
- Part XIV Laziness
- 37 Lazy Evaluation
- 38 Polarization
- Part XV Parallelism
- Part XVI Concurrency
- Part XVII Modularity
- Part XVIII Equational Reasoning
- Part XIX Appendix
- Bibliography
- Index
Summary
Lazy evaluation refers to a variety of concepts that seek to defer evaluation of an expression until it is definitely required and to share the results of any such evaluation among all instances of a single deferred computation. The net result is that a computation is performed at most once among all of its instances. Laziness manifests itself in a number of ways.
One form of laziness is the by-need evaluation strategy for function application. Recall from Chapter 8 that the by-name evaluation order passes the argument to a function in unevaluated form so that it is evaluated only if it is actually used. But because the argument is replicated by substitution, it may be evaluated more than once. By-need evaluation ensures that the argument to a function is evaluated at most once by ensuring that all copies of an argument share the result of evaluating any one copy.
Another form of laziness is the concept of a lazy data structure. As we have seen in Chapters 11, 12, and 16, we may choose to defer evaluation of the components of a data structure until they are actually required rather than when the data structure is created. But if a component is required more than once, then the same computation will, without further provision, be repeated on each use. To avoid this, the deferred portions of a data structure are shared so an access to one will propagate its result to all occurrences of the same computation.
- Type
- Chapter
- Information
- Practical Foundations for Programming Languages , pp. 307 - 315Publisher: Cambridge University PressPrint publication year: 2012