Book contents
- Frontmatter
- Contents
- Preface
- 1 Introduction
- 2 Persistence
- 3 Some Familiar Data Structures in a Functional Setting
- 4 Lazy Evaluation
- 5 Fundamentals of Amortization
- 6 Amortization and Persistence via Lazy Evaluation
- 7 Eliminating Amortization
- 8 Lazy Rebuilding
- 9 Numerical Representations
- 10 Data-Structural Bootstrapping
- 11 Implicit Recursive Slowdown
- A Haskell Source Code
- Bibliography
- Index
6 - Amortization and Persistence via Lazy Evaluation
Published online by Cambridge University Press: 17 September 2009
- Frontmatter
- Contents
- Preface
- 1 Introduction
- 2 Persistence
- 3 Some Familiar Data Structures in a Functional Setting
- 4 Lazy Evaluation
- 5 Fundamentals of Amortization
- 6 Amortization and Persistence via Lazy Evaluation
- 7 Eliminating Amortization
- 8 Lazy Rebuilding
- 9 Numerical Representations
- 10 Data-Structural Bootstrapping
- 11 Implicit Recursive Slowdown
- A Haskell Source Code
- Bibliography
- Index
Summary
The previous chapter introduced the idea of amortization and gave several examples of data structures with good amortized bounds. However, for each these data structures, the amortized bounds break in the presence of persistence. In this chapter, we demonstrate how lazy evaluation can mediate the conflict between amortization and persistence, and adapt both the banker's and physicist's methods to account for lazy evaluation. We then illustrate the use of these new methods on several amortized data structures that use lazy evaluation internally.
Execution Traces and Logical Time
In the previous chapter, we saw that traditional methods of amortization break in the presence of persistence because they assume a unique future, in which the accumulated savings will be spent at most once. However, with persistence, multiple logical futures might all try to spend the same savings. But what exactly do we mean by the “logical future” of an operation?
We model logical time with execution traces, which give an abstract view of the history of a computation. An execution trace is a directed graph whose nodes represent operations of interest, usually just update operations on the data type in question. An edge from v to v′ indicates that operation v′ uses some result of operation v.
- Type
- Chapter
- Information
- Purely Functional Data Structures , pp. 57 - 82Publisher: Cambridge University PressPrint publication year: 1998