Closure Under Alpha-Conversion

ion, compute a type for its body in an extended context; to compute a type for an application, compute types for its left and right components, and check that they match appropriately. Lets use the algorithm to compute a type for a = [x: ][x: ]x. FAILURE: no rule applies because x 2 Dom (x: ) x: ; x: valid x: ; x: ` x : ? x: ` [x: ]x : ! ? ` [x: ][x: ]x : ! !? (1) This system fails to derive the intended type ! ! . Notice that ` [x: ][y: ]y : ! ! is derivable, but the system is not closed under alphaconversion of subjects. What went wrong? In directly implementing this system we are taking informal notation too literally: there is no \x" in [x: ][x: ]x; the names of bound variables are not meant to be taken seriously. The rule lda should be read as \in order to type [x: ]M , choose some suitable alpha-representative of [x: ]M , : : :". Formal systems with variable binding are implemented on machines as the basis of programming languages and proof checkers, among other applications. It is clear that the concrete syntax that users enter into such implementations, and see printed by the implementation in response, should be formally related to the implemented formal system. Further, users and implementors need an exact and concise description of such a system; informal explanation is not good enough. The concrete syntax should have good properties. Users of such implemented systems will construct large formal objects with complex binding. The implementation should help in this task, and anamolies of naming such as the small example above make the job more di cult. What do you say to an ML implementation that claims fn x => fn x => x is not well typed? There are several approaches to naming in implementations of formal systems. Perhaps the best known is the use of explicit names, and Curry-style renaming in the de nition of substitution. This technique can (probably) be formalized. The di culty arises when we ignore the distinction between alphaconvertible terms, and treat then as equal. It is well known that one solution to the problems of alpha-conversion is the use of de Bruijn \nameless variables" [dB72]. Although nameless variables have their partisans for use in metatheoretic study, even those partisans admit that the explanation of substitution of a term for a given variable is painful in such a presentation, although it can be, and has been, carried out elegantly [Alt93, Hue94]3. However, the direct use of nameless variables is not a real possibility in pragmatic applications because human users nd it di cult to write even small expressions using nameless variables. It is necessary to translate from named syntax to nameless, and then back again to named syntax for pretty printing, and this translation itself must be formalized. I know of two recent proposals that take names seriously, but avoid the need for alpha-conversion. One proposal, by Coquand [Coq91], follows a style in logic to distinguish between free variables (parameters) and bound variables (variables). This idea has been used to formalize a large theory of Pure Type Systems, including reduction, conversion and typing [MP93]. This formalization does distinguish between alpha-convertible terms, and the typing judgement is indeed closed under alpha-conversion. The other proposal, by Martin-L of [Tas93] goes much further, not only using explicit names, but also explicit substitutions, i.e. making the notion of substitution a part of the formal system (as originally proposed for nameless terms in [ACCL91]). Unfortunately the system of [Tas93], in its current formulation, is not closed under alpha-conversion; e.g. it fails to derive judgement (7) in section 3. Finally, there is a recent proposal [Gor93] of a formalization mixing nameless terms and named variables in such a way that named terms are equal up to alpha-conversion. 1.1 The Constructive Engine The Constructive Engine [Hue89] is an abstract machine for type checking the Calculus of Constructions. It is the basis for the proofcheckers Coq [DFH+93] and LEGO [LP92]. Among its interesting aspects are: 1. the non-deterministic rules of the underlying type theory are converted into a deterministic, syntax-directed program 2. this syntax-directed program implements a relation equivalent to the type theory, but with very much smaller derivations 3. external concrete syntax with explicit variable names is translated into internal abstract syntax of locally nameless terms, that is, local binding by de Bruijn indexes, and global binding by explicit names 4. an e cient technique for testing conversion of locally nameless terms (with special attention to the treatment of de nitions) The basic ideas of the rst and second of these points appeared in early writing of Martin-L of. The rst point has been studied extensively [Pol92, vBJMP94] for the class of Pure Type Systems. The second point is addressed in [vBJMP94, Pol94]. The fourth point (which is clearly the remaining limiting factor in pragmatic implementations of proof checkers) has not received any theoretical attention to my knowledge, although [Hue89, dB85] suggest interesting ideas. 3 For an example of metatheory where nameless variables are very inconvenient, see the discussion of the Thinning Lemma in [MP93] In this note I focus on the third item above, the relationship between concrete syntax and abstract syntax in the Constructive Engine. The use of locally nameless style for internal representation of terms is one of the basic decisions of the Constructive Engine, but perhaps re ects more Huet's interest in experimenting with de Bruijn representation than any ultimate conviction that they are the \right" notation for implementing a type checker. I do not want to study the pros and cons of this representation for e cient typechecking, but only to muse over the relationship between concrete terms, their abstract representations, and their (abstract) types. Plan of the paper. In the next section we discuss simply-typed lambda calculus, !. After presenting several concrete and abstract presentations of its typing rules, we derive a Constructive Engine for !, and consider some variations. In section 3 we consider the same issue for Pure Type Systems (PTS). There is one new problem in the case of dependent types. We explain a constructive engine for dependent types, and show how to make it closed under alpha-conversion of terms. AcknowledgementA careful and knowledgeable referee made many useful suggestions. 2 Simply typed lambda calculus There is a crude way to close the relation ` of the Introduction under alphaconversion of subjects, by adding a rule alpha ` M : ` N : M = N where M = N , alpha-conversion, must also be de ned by some inductive de nition. Such solutions are heavy, and not ideal for either implementation or formal meta-reasoning. Instead of reasoning about three or ve rules, we'll have to reason about all the rules for = as well. Further, rules such as alpha, that are not syntax-directed, are hard to reason about: being non-deterministic, they allow many derivations of the same judgement, which sometimes prevents proof by induction on the structure of derivations. 2.1 A concrete presentation closed under alpha-conversion Another approach is to formalize the informalmeaning of the lda rule suggested above: choose a su ciently fresh variable name to substitute for x. Informally, replace lda by ; y: `s M [y=x] : `s [x: ]M : ! y 62M Substitution of y for x in M must still be de ned, and the usual de nition involves alpha-conversion. We give a formulation suggested in [Coq91] and formalized in detail in [MP93]. Let p, q, r, range over an in nite set of parameters, and x, y, z over variables as before. Parameters and variables are disjoint sets4. De ne two operations of replacement. Replacing a parameter by a term is entirely textual: x[M=p] = x q[M=p] = if p = q then M else q ([x: ]N)[M=p] = [x: ]N [M=p] (N1N2)[M=p] = (N1[M=p]) (N2[M=p]) Replacing a variable by a term does respect the scope of variable binding but does not rename variables to prevent capture: x[M=y] = if y = x then M else x q[M=y] = q ([x: ]N)[M=y] = [x: ](if y = x then N else N [M=y]) (N1N2)[M=y] = (N1[M=y]) (N2[M=y]) Now replace lda by s-lda ; p: `s M [p=x] : `s [x: ]M : ! p 62M (where p 2 M means textual occurrence). In the side condition of this rule, it's not necessary to check that p 62 Dom ( ) because failure of that condition prevents completing a derivation; just choose another parameter, since p does not occur in the conclusion of the rule. It is necessary to check p 62M so that the premiss doesn't bind instances of p that do not arise from x. We could de ne beta-reduction, beta-conversion, prove Church-Rosser, subject reduction, etc. [MP93], but for our purposes alpha-conversion is enough: -refl M = M -lda M [p=x] =M 0[p=y] [x: ]M = [y: ]M 0 p 62M; p 62M 0 -app M = M 0 N = N 0 M N = M 0N 0 Now we can state and prove `s is closed under alpha-conversion 4 Another informality! What is required is that the terms p and x be distinguishable, not necessarily that the underlying objects be. Depending on the formalization of terms we might use weaker conditions. In [MP93], where terms are an inductive type with distinct constructors for parameters and variables, we don't require parameters and variables to be distinct. In informal presentations of logic it is common for \term" to be an inductive relation on strings over some alphabet; in this case, of course, we require that (distinct) objects of the alphabet be distinct. Lemma1 Closure of `s under alpha-conversion. If `s M : and M =M 0 then `s M 0 : This can be proved following the same outline as a proof of subject reduction (closure under beta-reduction); in fact = is contained in parallel reduction, so this lemma is a corollary of subject reduction. `s still treats parameters seriously: `s [x: ][x: ]x : ! ! but p: ; p: 6`s p : : This is a di erent problem, if it is a problem at all. In `s we have analysed the