Elf: A Language for Logic Definition and Verified Metaprogramming Frank Pfenning School of Computer Science Carnegie Mellon University Pittsburgh, Pennsylvania 15213-3890 Internet: [email protected] Abstract 1 Introduction There is a wide variety of deductive systems consid- We describe Elf, a metalanguage for proof manipula- ered in computer science today (for example Hoare tion environments that are independent of any partic- logics, type theories, type deduction systems, opera- ular logical system. Elf is intended for meta-programs tional semantics specifications, first- and higher-order such as theorem provers, proof transformers, or type intuitionistic and classical logics). Mechanized sup- inference programs for programming languages with port for deduction in a variety of logics and type the- complex type systems. Elf unifies logic definition (in ories has been the subject of much research (see, for the style of LF, the Edinburgh Logical Framework) example, Automath [6], LCF [12], HOL [13], Calculus with logic programming (in the style of λProlog). It of Constructions [5], Isabelle [25], NuPrl [3]). achieves this unification by giving types an operational In [15], Harper, Honsell, and Plotkin present LF (the interpretation, much the same way that Prolog gives Edinburgh Logical Framework) as a general metathe- certain formulas (Horn-clauses) an operational inter- ory for the definition of logics. LF provides a uni- pretation. Novel features of Elf include: (1) the Elf form way of encoding a logical language, its infer- search process automatically constructs terms that can ence rules and its proofs. In [1], Avron, Honsell, and represent object-logic proofs, and thus a program need Mason give a variety of examples for encoding logics not construct them explicitly, (2) the partial correct- in LF. Griffin’s EFS (Environment for Formal Sys- ness of meta-programs with respect to a given logic tems, see [14]) is an implementation that allows defi- can be expressed and proved in Elf itself, and (3) Elf nition of logics and interactive theorem proving in LF. exploits Elliott’s unification algorithm for a λ-calculus EFS provides a nice syntactic environment, but lacks with dependent types. meta-programming support, this is, it lacks a metalan- guage for programming theorem proving, type infer- ence, proof transformation, and similar tasks. We be- lieve that good meta-programming support is essential This research was supported in part by the Office of Naval to obtain adequate theorem proving assistance in an Research under contract N00014-84-K-0415 and in part by the environment that is basically independent of any par- Defense Advanced Research Projects Agency (DOD), ARPA Or- der No. 5404, monitored by the Office of Naval Research under ticular logical system. A signature that defines a logic the same contract. in LF simply does not contain enough information—it specifies an inference system, but not a useful theorem prover. In this paper we describe Elf, a metalanguage in- tended for theorem proving and proof manipulation environments. Its range of applications therefore in- To appear at the Fourth Annual Symposium on clude the range of applications of such environments Logic in Computer Science, Asilomar, California, (as indicated above). The basic idea behind Elf is to June 5-8, 1989. unify logic definition (in the style of LF) with logic pro- Elf 2 gramming (in the style of λProlog, see [22, 21, 24]). It that makes it much more palatable as an implemen- achieves this unification by giving types an operational tation language. Experience with λProlog shows that interpretation, much the same way that Prolog gives the commitment to depth-first search results in a use- certain formulas (Horn-clauses) an operational inter- ful programming language, even though the underlying pretation. unification problem is in general only semi-decidable. Here are some of the salient characteristics of this In Section 5 we give excerpts from some example Elf unified approach to logic definition and metaprogram- programs. An implementation of Elf in Common Lisp ming. First of all, the Elf search process automati- is currently in progress in the framework of the Ergo cally constructs terms that can represent object-logic project at Carnegie Mellon University. proofs, and thus a program need not construct them explicitly. This is in contrast to logic programming 2 The base language λΠΣ languages, where executing a logic program corre- The base language for Elf, λ ,isthetypetheoryof sponds to theorem proving in a meta-logic, but a meta- ΠΣ LF [15], λ , enriched by a Σ type constructor. The proof is never constructed or used and it is solely Π motivation for extending the LF type theory by Σ are the programmers responsibility to construct object- discussed in Section 4.4. We are excluding the λ type logic proofs. Secondly, Elf avoids the undesirable op- family constructor as a matter of convenience—in the erational behavior of meta-programs that sometimes formulation of LF in [15], λ at the level of types does arises from encoding a logic in higher-order logic as not appear in normal forms of types and thus seems done in Isabelle [25] and by Felty and Miller in [11] essential only for the formulation of type inference al- (see the example in Section 5.3). Finally, the partial gorithms. To simplify the presentation we consider α- correctness of meta-programs with respect to a given convertible terms to be identical and also assume that logic can be expressed and proved by Elf itself (see the all constants in a signature and variables in a context example in Section 5.2). This creates the possibility are distinct. of deriving verified meta-programs through theorem proving in Elf (see Constable, Knoblock & Bates [4], 2.1 Syntax Knoblock & Constable [19] or Howe [17] for other ap- proaches). There are five syntactic categories, just as in λΠ.In order to be consistent with the notation in [15] we The base language λΠΣ for Elf is the LF type the- ory (a simply typed λ-calculus extended to allow de- overloaded the symbol Σ to stand for signatures and pendent function types), enriched with strong sums also be used as a type constructor. It should always be obvious which one is meant. We will use M and N (which we prefer to call dependent products). Unlike in λProlog, no restriction on goals or programs needs to stand for terms, A and B to stand for types, and K to be made: the completeness theorem for our ab- to stand for kinds. stract interpreter guarantees that goal-directed search Signatures Σ ::= hi | Σ,c:K |Σ,c:A is complete. Thus, Elf is a language in the spirit of Contexts Γ ::= hi | Γ,x:A Miller, Nadathur, Pfenning and Scedrov’s [21] def- inition of an abstract logic programming language, Kinds K ::= Type | Πx:A.K | | | though it is not based on logic but on the λΠΣ type Type Families A ::= c AM Πx:A.B Σx:A.B theory. Terms M ::= c | x | λx:A.M|MN |(M, N) | fst M | snd M The abstract interpreter, formulated as a transition system, is described in Section 3. Transitions corre- → spond either to unification steps or steps in a goal- We will use the abbreviations A B for Πx:A. × directed search for a term of the given type. The uni- Bwhen x is not free in B,andA Bfor Σx:A. fication steps are based on an extensions of Elliott’s Bwhen x is not free in B.[M/x]N,[M/x]A,and unification algorithm on terms in the LF type theory [M/x]K are our notation for substitution, renaming (see [7] and [8]). The non-deterministic interpreter is bound variables if necessary to avoid name clashes. made practical by a commitment to depth-first search, Atomic types C are types that begin with neither a Π a distinction between open and closed judgments and nor a Σ. dynamic and static constants, and the addition of the 2.2 Typing rules cut search directive familiar from Prolog (see Sec- tion 4). The language environment includes a notion We adopt the presentation from [15] and add the fol- of module and a term and type-inference algorithm lowing rules for dependent products (strong sums): Elf 3 2. All well-typed terms are strongly normalizing. 3. Type-checking and kind-checking is decidable. Γ `Σ A ∈ Type Γ,x:A`Σ B ∈Type Γ `Σ Σx:A.B∈Type Proof sketch: The proof is an extension of the Γ `Σ M ∈ A Γ `Σ N ∈ [M/x]B one in [15]. Church-Rosser for this weak notion of Γ `Σ (M, N) ∈ Σx:A.B conversion can be proved as in [15], since it holds for all, and not only for well-typed terms. To prove strong Γ` M∈Σx:A.B Γ ` M ∈ Σx:A.B Σ Σ normalization, we translate both types and terms from Γ`Σ fst M ∈ A Γ`Σ snd M ∈ [fst M/x]B λΠΣ into terms in a simply typed λ-calculus with prod- 2.3 Conversion rules ucts and explicit types. It follows from a the strong normalization theorem by Troelstra [28] for a simply When choosing a notion of conversion for λΠΣ there typed λ-calculus (even including η and surjective pair- is an unfortunate tradeoff. From a practical point ing) that such terms are strongly normalizing which in of view (both for the encoding of inference systems turn implies this for the original terms with dependent in λΠΣ and for the implementation of Elf) one would types. like βη-reduction and the rules for surjective pairing. Under strong conversion, only the proof of strong Unfortunately, the Church-Rosser property for well- normalization for well-typed terms can be extended typed terms under this notion of reduction is still open, in a straightforward way, as indicated in the proof though we conjecture that it holds.