Church Encoding of Data Types Considered Harmful for Implementations

Abstract

From the λ-calculus it is known how to represent (recursive) data structures by ordinary λ-terms. Based on this idea one can represent algebraic data types in a functional programming language by higher-order functions. Using this encoding we only have to implement functions to achieve an implementation of the functional language with data structures. In this paper we compare the famous Church encoding of data types with the less familiar Scott and Parigot encodings.We show that one can use the encoding of data types by functions in a Hindley-Milner typed language by adding a single constructor for each data type. In an untyped context, like an efficient implementation, this constructor can be omitted. By collecting the basic operations of a data type in a type constructor class and providing instances for the various encodings, these encodings can coexist in a single program. By changing the instance of this class we can execute the same algorithm in a different encoding. This makes it easier to compare the encodings with each other.We show that in the Church encoding selectors of constructors yielding the recursive type, like the tail of a list, have an undesirable strictness in the spine of the data structure. The Scott and Parigot encodings do not hamper lazy evaluation in any way. The evaluation of the recursive spine by the Church encoding makes the complexity of these destructors linear time. The same destructors in the Scott and the Parigot encoding requires only constant time. Moreover, the Church encoding has problems with sharing reduction results of selectors. The Parigot encoding is a combination of the Scott and Church encoding. Hence we might expect that it combines the best of both worlds, but in practice it does not offer any advantage over the Scott encoding.

Unraveling Recursion: Compiling an IR with Recursion to System F

“…Here the recursive occurrence of Nat has disappeared, replaced by an R. This is because while the Scott encoding corresponds to a pattern-match on a type, the Church encoding corresponds to a fold, so recursive occurrences have already been folded into the output type. This highlights the tradeoffs between the two encodings (see [19] for further discussion):…”

“…Different approaches to encoding datatypes are compared in [19]. The authors provide a schematic formal description of Scott encoding, but ours is more thorough and includes complete handling of recursive types.…”

The calculus of dependent lambda eliminations

“…s 1 (s 0 z). While in theory the space required for normal forms is exponential, in practice closure-based implementations of lambda calculus compute efficiently with Parigot encodings, as has been found in several studies (Koopman et al, 2014;Stump & Fu, 2016). And Parigot encodings can be typed in a normalizing extension of System F with positive-recursive types (cf.…”

Efficiency of lambda-encodings in total type theory

“…Because Haskell's directly supports only predicative polymorphism, newtype must be used to wrap higher rank types for instantiation of universally quantified type variables. A similar mechanism in Clean was used in a recent similar study (Koopman et al, 2014). We must use newtype even for the translations of non-recursive types like CNat, because of the restriction to predicative polymorphism.…”