Results 1 
8 of
8
Optimal Purely Functional Priority Queues
 JOURNAL OF FUNCTIONAL PROGRAMMING
, 1996
"... Brodal recently introduced the first implementation of imperative priority queues to support findMin, insert, and meld in O(1) worstcase time, and deleteMin in O(log n) worstcase time. These bounds are asymptotically optimal among all comparisonbased priority queues. In this paper, we adapt B ..."
Abstract

Cited by 18 (1 self)
 Add to MetaCart
Brodal recently introduced the first implementation of imperative priority queues to support findMin, insert, and meld in O(1) worstcase time, and deleteMin in O(log n) worstcase time. These bounds are asymptotically optimal among all comparisonbased priority queues. In this paper, we adapt Brodal's data structure to a purely functional setting. In doing so, we both simplify the data structure and clarify its relationship to the binomial queues of Vuillemin, which support all four operations in O(log n) time. Specifically, we derive our implementation from binomial queues in three steps: first, we reduce the running time of insert to O(1) by eliminating the possibility of cascading links; second, we reduce the running time of findMin to O(1) by adding a global root to hold the minimum element; and finally, we reduce the running time of meld to O(1) by allowing priority queues to contain other priority queues. Each of these steps is expressed using MLstyle functors. The last transformation, known as datastructural bootstrapping, is an interesting application of higherorder functors and recursive structures.
Bulk types with class
 In Proceedings of the Second Haskell Workshop
, 1996
"... Bulk types  such as lists, bags, sets, nite maps, and priority queues  are ubiquitous in programming. Yet many languages don't support them well, even though they have received a great deal of attention, especially from the database community. Haskell is currently among the culprits. This paper ha ..."
Abstract

Cited by 12 (1 self)
 Add to MetaCart
Bulk types  such as lists, bags, sets, nite maps, and priority queues  are ubiquitous in programming. Yet many languages don't support them well, even though they have received a great deal of attention, especially from the database community. Haskell is currently among the culprits. This paper has two aims: to identify some of the technical di culties, and to attempt to address them using Haskell's constructor classes. The paper can also be read as a concrete proposal for new Haskell bulk type libraries. 1
Making Data Structures Confluently Persistent
, 2001
"... We address a longstanding open problem of [10, 9], and present a general transformation that transforms any pointer based data structure to be confluently persistent. Such transformations for fully persistent data structures are given in [10], greatly improving the performance compared to the naive ..."
Abstract

Cited by 10 (0 self)
 Add to MetaCart
We address a longstanding open problem of [10, 9], and present a general transformation that transforms any pointer based data structure to be confluently persistent. Such transformations for fully persistent data structures are given in [10], greatly improving the performance compared to the naive scheme of simply copying the inputs. Unlike fully persistent data structures, where both the naive scheme and the fully persistent scheme of [10] are feasible, we show that the naive scheme for confluently persistent data structures is itself infeasible (requires exponential space and time). Thus, prior to this paper there was no feasible method for implementing confluently persistent data structures at all. Our methods give an exponential reduction in space and time compared to the naive method, placing confluently persistent data structures in the realm of possibility.
Functional Pearls: Explaining Binomial Heaps
, 1999
"... This paper explains binomial heaps, a beautiful data structure for priority queues, using the functional programming language Haskell (Peterson & Hammond, 1997). We largely follow a deductive approach: using the metaphor of a tennis tournament we show that binomial heaps arise naturally through a nu ..."
Abstract

Cited by 5 (4 self)
 Add to MetaCart
This paper explains binomial heaps, a beautiful data structure for priority queues, using the functional programming language Haskell (Peterson & Hammond, 1997). We largely follow a deductive approach: using the metaphor of a tennis tournament we show that binomial heaps arise naturally through a number of logical steps. Haskell supports the deductive style of presentation very well: new types are introduced at ease, algorithms can be expressed clearly and succinctly, and Haskell's type classes allow to capture common algorithmic patterns. The paper aims at the level of an undergraduate student who has experience in reading and writing Haskell programs, and who is familiar with the concept of a priority queue. 2 Priority queues
Numerical Representations as HigherOrder Nested Datatypes
, 1998
"... Number systems serve admirably as templates for container types: a container object of size n is modelled after the representation of the number n and operations on container objects are modelled after their numbertheoretic counterparts. Binomial queues are probably the first data structure that wa ..."
Abstract

Cited by 5 (2 self)
 Add to MetaCart
Number systems serve admirably as templates for container types: a container object of size n is modelled after the representation of the number n and operations on container objects are modelled after their numbertheoretic counterparts. Binomial queues are probably the first data structure that was designed with this analogy in mind. In this paper we show how to express these socalled numerical representations as higherorder nested datatypes. A nested datatype allows to capture the structural invariants of a numerical representation, so that the violation of an invariant can be detected at compiletime. We develop a programming method which allows to adapt algorithms to the new representation in a mostly straightforward manner. The framework is employed to implement three different container types: binary randomaccess lists, binomial queues, and 23 finger search trees. The latter data structure, which is treated in some depth, can be seen as the main innovation from a datastruct...
Auburn: A Kit for Benchmarking Functional Data Structures
 LECTURE NOTES IN COMPUTER SCIENCE
, 1997
"... Benchmarking competing implementations of a data structure can be both tricky and time consuming. The efficiency of an implementation may depend critically on how it is used. This problem is compounded by persistence. All purely functional data structures are persistent. We present a kit that c ..."
Abstract

Cited by 4 (3 self)
 Add to MetaCart
Benchmarking competing implementations of a data structure can be both tricky and time consuming. The efficiency of an implementation may depend critically on how it is used. This problem is compounded by persistence. All purely functional data structures are persistent. We present a kit that can generate benchmarks for a given data structure. A benchmark is made from a description of how it should use an implementation of the data structure. The kit will improve the speed, ease and power of the process of benchmarking functional data structures.
Benchmarking Purely Functional Data Structures
 Journal of Functional Programming
, 1999
"... When someone designs a new data structure, they want to know how well it performs. Previously, the only way to do this involves finding, coding and testing some applications to act as benchmarks. This can be tedious and timeconsuming. Worse, how a benchmark uses a data structure may considerably af ..."
Abstract

Cited by 2 (0 self)
 Add to MetaCart
When someone designs a new data structure, they want to know how well it performs. Previously, the only way to do this involves finding, coding and testing some applications to act as benchmarks. This can be tedious and timeconsuming. Worse, how a benchmark uses a data structure may considerably affect the efficiency of the data structure. Thus, the choice of benchmarks may bias the results. For these reasons, new data structures developed for functional languages often pay little attention to empirical performance. We solve these problems by developing a benchmarking tool, Auburn, that can generate benchmarks across a fair distribution of uses. We precisely define "the use of a data structure", upon which we build the core algorithms of Auburn: how to generate a benchmark from a description of use, and how to extract a description of use from an application. We consider how best to use these algorithms to benchmark competing data structures. Finally, we test Auburn by benchmarking ...
Lenient evaluation is neither strict nor lazy
, 2000
"... What is a nonstrict functional language? Is a nonstrict language necessarily lazy? What additional expressiveness brings nonstrictness, with or without laziness? This paper tries to shed some light on these questions. First, in order to characterize nonstrictness, different evaluation strategies ..."
Abstract
 Add to MetaCart
What is a nonstrict functional language? Is a nonstrict language necessarily lazy? What additional expressiveness brings nonstrictness, with or without laziness? This paper tries to shed some light on these questions. First, in order to characterize nonstrictness, different evaluation strategies are introduced: strict, lazy, and lenient. Then, using program examples, how these evaluation strategies differ from each other is examined, showing that nonstrictness, even without laziness, allows a more general use of recursive definitions. We also report on a small experiment that we performed to examine how, in practice, laziness was used in a number