The Derivative of a Regular Type Is Its Type of One-Hole Contexts

The Derivative of a Regular Type is its Type of One-Hole Contexts Extended Abstract Conor McBride Abstract subtraction, an operation inherently troubled by the need to subtract only smaller things from larger, but as the in- version of a kind of addition (see figure 1). Polymorphic regular types are tree-like datatypes gen- erated by polynomial type expressions over a set of free variables and closed under least fixed point. The ‘equality types’ of Core ML can be expressed in this form. Given ¡ such a type expression with ¢ free, this paper shows a = + way to represent the one-hole contexts for elements of ¢ within elements of ¡ , together with an operation which will plug an element of ¢ into the hole of such a context. One-hole contexts are given as inhabitants of a regular ¡ type £¥¤ , computed generically from the syntactic structure of ¡ by a mechanism better known as partial differ- Figure 1: a tree as a one-hole context ‘plus’ a subtree entiation. The relevant notion of containment is shown to be appropriately characterized in terms of derivatives and This paper exhibits a similar technique, defined more for- plugging in. The technology is then exploited to give the mally, which is generic for a large class of tree-like data one-hole contexts for sub-elements of recursive types in a structures—the ‘regular datatypes’. These are essentially manner similar to Huet’s ‘zippers’[Hue97]. the ‘equality types’ of core ML, presented as polynomial type expressions closed under least fixed point. In particular, I will define and characterize two operations: 1 Introduction § on types, computing for each regular recursive Gerard´ Huet’s delightful paper ‘The Zipper’ [Hue97] de- datatype its type of one-hole contexts; fines a representation of tree-like data decomposed into a subtree of interest and its surroundings. He shows us in- § on terms, computing a ‘big’ term by plugging a formally how to equip a datatype with an associated type ‘small’ term into a one-hole context. of ‘zippers’—one-hole contexts representing a tree with one subtree deleted. Zippers collect the subtrees forking The first of these operations is given by recursion on the off step by step from the path which starts at the hole and structure of the algebraic expressions which ‘name’ types. returns to the root. This type of contexts is thus indepen- As I wrote down the rules corresponding to the empty dent of the particular tree being decomposed or the sub- type, the unit type, sums and products, I was astonished tree in the hole. Decomposition is seen not as a kind of to find that Leibniz had beaten me to them by several cen- ¦ Department of Computer Science, University of Durham, turies: they were exactly the rules of differentiation I had [email protected] learned as a child. 1 1.1 Motivating Examples btree @¨ 2 btree How can we describe the one-hole contexts of a recur- Now imagine similar journeys list ttree for ternary sive type? Huet suggests that we regard them as journeys trees: ‘backwards’ from hole to root, recording what we pass by on the way. I propose to follow his suggestion, except that 3 ttree ¨ 1 ttree I will start at the root and work my way ‘forwards’ to the hole. Both choices have their uses: ‘backwards’ is better for ‘tree editing’ applications, but the ‘forwards’ approach Each step chooses one of three directions, and remembers is conceptually simpler. two bypassed trees, so Consider such journeys within binary trees: 2 ttree ¨ 3 ttree © btree ¨ leaf node btree btree It looks remarkably like the type of steps is calculated by differentiating the original datatype. In fact, this is exactly At each point, we are either at the hole or we must step what is happening, as we shall see when we examine how further in—our journey is a list of steps, list btree for to compute the description of the one-hole contexts for some appropriate step type btree , but what? At each regular datatypes. step, we must record our binary choice of left or right, together with the btree we passed by. We may take 2 Presenting the Regular Types btree ¨ bool btree 1 In order to give a precise treatment of ‘differentiating a We can define the ‘plugging in’ operation as follows datatype’, we must be precise about the expressions which define them. In particular, the availability of fixed points btree btree requires us to consider the binding of fresh type variables. btree There is much activity in this area of research, but this is not the place to rehearse its many issues. The approach true node I take in this paper relativizes regular type expressions to ¥ false node finite sequences of available free names. I then explain !"!# list btree btree how to interpret such expressions relative to an environ- !"! $ btree ment which interprets those names. % & $ I choose to give inductive definitions in natural deduc- (')'*!"! , !"! - + $ tion style. Although this requires more space than the datatype declarations of conventional programming lan- We might define btree more algebraically as the sum guages, they allow dependent families to be presented (i.e. ‘choice’) of the unique leaf with nodes pairing two much more clearly: even ‘nested’ types [BM98, BP99] subtrees—powers denote repeated product: must be defined uniformly over their indices, whilst the full notion of family allows constructors to apply only 2 at particular indices. I also give type signatures to de- btree ¨ 1 btree fined functions in this way, preferring to present the uni- versal quantification inherent in their type dependency via Correspondingly, we might write schematic use of variables, rather than by complex and in- 1 >[email protected]/+B:C6 Huet would write .0/+12143537698;:=< scrutable formulae. 2 2.1 Sequences of Distinct Names family Reg D in figure 2. Firstly, we embed3 type vari- D ables D in Reg , then we give the building blocks for Let us presume the existence of an infinite2 set Name of polynomials and least fixed point. names, equipped with a decidable equality. We may think D of Name as being ‘string’. The set NmSeq may then be NmSeq D defined to contain the finite sequences of distinct names. Reg Set Each such sequence can be viewed ‘forgetfully’ as a set. D ¢ D ¢ Reg D ¡ D NmSeq D Reg D O ¡ D Name Set Set 0 Reg Reg O ¡ D D D Reg ¢ ¢GF D D ¡ NmSeq Name O D=H E 1 Reg Reg ¢ NmSeq NmSeq O P D=H Reg ¢ P D Q ¢ . Reg I shall always use names in a well-founded manner. The P D=H D ¡ D D ¢ ‘explanation’ of some name ¢ from some sequence will Reg Reg Reg P D ¡ D=H O © ¢ ¢ = Reg ¤ Reg involve only ‘prior’ names—intuitively, those which have O already been explained. It is therefore important to define DGI for any such pair, the restriction ¢ , being the sequence D Figure 2: descriptions of regular types of names from prior to ¢ . D D The last two constructors may seem mysterious. How- NmSeq ¢ DGI ever, the redundancy they introduce will save us work ¢ NmSeq when we come to interpret these descriptions of types. E I D D=H We could choose to interpret only Reg , the closed de- ¢ ¢ KJML I DGI D=H scriptions, keeping the open types underwater like the ¢ ¢ ¢N dangerous bits of an iceberg. This would require us to substitute for free names whenever they become exposed, As equality on names is decidable, I shall freely allow for example, when expanding a fixed point. We would in names to occur nonlinearly in patterns. In order to re- turn be forced to take account of the equational properties cover the disjointness of patterns without recourse to pri- of substitutions and prove closure properties with respect JML oritizing them, I introduce the notation ¢ to mean ‘any to them. I dispense with substitution. J except ¢ ’. Correspondingly, each clause of such a definition holds (schematically) as an equation. I nonetheless The alternative I have adopted is to interpret open descriptions in environments which explain their free names. The write to indicate a directed computation rule, reserving two unusual constructors above perform the rolesˆ of defi- ¨ for equational propositions. nition and weakening, respectively growing and shrinking the environment within their scope. Definition replaces 2.2 Describing the Regular Types substitution and weakening adds more free names without modifying ‘old’ descriptions. This avoids the propagation of substitutions through the syntactic structure and hence The regular types over given free names, or rather, the ex- concerns about capture—we shall only ever interpret the pressions which describe them are given by the inductive ‘value’ of a variable in its binding-time environment. 2By ‘infinite’, I mean that I can always choose a fresh name if I need to create a new binding. 3In fact I am abusing notation by suppressing a constructor symbol. 3 D ¡ D 2.3 Type Environments R Env Reg % % & & ¡ R Set D % % & & I A type environment for a given name sequence asso- R ¢ RTSU¢ D % % & & ciates each ¢ in with a type description over the prior R ¢ DGI ¢ % & & % % & & names, . % ¡ R R % % & & % % & & O ¡ ¡ R inl R inr O O D % % & & % % & & ¡ NmSeq # D R R XZY % % & & X Y % % & & O ¡ Env Set H R R 1 O & & % % P P E E Q R © ¢ ¢ Env = . % % & & P Q D=H D D R ¢ con . R ¢ NmSeq Env Reg H D=H O % % & & % % & & H P ¡ ¢ ¢ R = Env O R ¢ R = % % & & % % & & O P H ¡ R © ¢ R ¢ = = ¤ O O We may equip environments with operators for restriction (extracting the prefix prior to a given name) and projection I Figure 3: the data in regular types ¢ (looking up a name’s associated type description).

Load more