A Translation-Based Animation of Specifications in a - PowerPoint PPT Presentation

A Translation-Based Animation of Specifications in a Dependently-Typed Lambda Calculus Mary Southern and Gopalan Nadathur Department of Computer Science and Engineering University of Minnesota Other Contributors: D. Baelde, Z. Snow

The Context and Objective for this Work We are interested in formalizing systems that are described in a rule-based and syntax directed fashion Two approaches with complementary benefits exist for formalizing such systems that also manipulate objects with binding structure: ◮ An approach based on using dependently-typed λ -calculi Primary Virtue : Dependent types are a convenient and widely used means for encoding specifications ◮ An approach that uses logical predicates over λ -calculus terms Primary Virtues : Such a logic has an efficient implementation and specifications in it can also be expressively reasoned about Our Goal: To harness the benefits of both approaches Specifically, we want to ◮ let the first approach be used for developing specifications ◮ use a translation to the second form to realize animation

Overview of the Talk We will cover the following topics in this talk ◮ The dependently typed λ -calculus approach ◮ The predicate logic approach ◮ A translation from the first to the second ◮ Conclusion and future work

Specifications ◮ Syntax driven, rule based specifications Lists L := [] | ( N :: L ) Append - append L 1 L 2 L 3 append L 1 L 2 L 3 append [] L L append ( N :: L 1 ) L 2 ( N :: L 3 )

Edinburgh Logical Framework (LF) Syntax of Expressions Kind K := Type | Π x : A . K Type A := a | Π x : A . B | A M Object M := c | x | λ x : A . M | M N Notation: Write A → B for Π x : A . B if x is not free in B list : Type nil : list cons : nat → list → list append : list → list → list → Type : Π L : list . append nil L L appNil appCons : Π N : nat . Π L 1 : list . Π L 2 : list . Π L 3 : list . append L 1 L 2 L 3 → append ( cons N L 1 ) L 2 ( cons N L 3 ) Signature A signature identifies constants and provides their types (kinds). Judgement Γ ⊢ Σ M : A

Logic Programming with Twelf Solve judgments of the form · ⊢ Σ M : A . ◮ Types as formulas ◮ Terms as derivations ◮ Proof search becomes a question of inhabitation Example append : list → list → list → type appNil : append nil L L appCons : append L 1 L 2 L 3 → append ( cons X L 1 ) L 2 ( cons X L 3 ) Query: · ⊢ Σ M : append ( cons z nil ) nil ( cons z nil ) Solution: M = appCons z nil nil nil ( appNil nil )

Specifications Using a Predicate Logic In this setting, we use the following ideas to encode a formal system ◮ We identify predicates to represent relevant judgements ◮ We then use formulas to encode the rules for determining when these judgements hold Ideally, we would want the formulas also to capture the way the rules can be used to construct derivations in the object system To realize this requirement, we must restrict the permitted formulas to obtain the desired proof search behavior A logic with these properties is that of higher-order hereditary Harrop formulas that underlies the λ Prolog language

Higher-Order Hereditary Harrop Formulas ( hohh ) The atomic formulas in this logic are constructed using predicate symbols that take simply typed λ -terms as arguments The formulas that are used are then the following D := A | G ⊃ D | ∀ x . D G := ⊤ | A | D ⊃ G | ∀ x . G A collection of D -formulas encodes a specification and a G formula corresponds to a query For example, the list specification can be formalized as follows: list : type : list nil cons : ( nat → list → list ) : ( list → list → list → o ) append ∀ l . ( append nil l l ) ∀ x . ∀ l 1 . ∀ l 2 . ∀ l 3 . ( append l 1 l 2 l 3 ) ⊃ ( append ( cons x l 1 ) l 2 ( cons x l 3 ))

From LF specifications to hohh specifications The translation is based on a two step process 1. First we map both LF types and objects into simply typed λ -terms. ◮ we use hohh terms of type lf-type for LF types ◮ we use hohh terms of type lf-obj for LF objects Notice that the LF typing information is lost in this translation and only the functional structure of expressions is retained 2. We then encode LF typing relations in predicates over hohh terms denoting LF objects and LF types In particular, ◮ the predicate hastype : lf-obj → lf-type → o is used in this encoding ◮ A type itself becomes a formula of one arguement that should be satisfied by any term that has that type

The Translation of LF Types Let � U � denote the simply typed λ -term representing the LF object or type U Then, LF types are translated as follows: { { A } } := λ M . hastype M � A � if A is a base type { { Π x : A . B } } := λ M . ∀ x . ( { { A } } x ) ⊃ ( { { B } } ( M x )) For example, consider the translation of Π L : list . append nil L L : { { Π L : list . append nil L L } } λ M . ∀ L . ( { { list } } L ) ⊃ ( { { append nil L L } } ( M L )) λ M . ∀ L . ( hastype L list ) ⊃ ( hastype ( M L ) ( append nil L L )) Thus, the LF signature item appNil : Π L : list . append nil L L yields the hohh clause ∀ L . ( hastype L list ) ⊃ ( hastype ( appNil L ) ( append nil L L )

A Deficiency with the Translation We are interested in finding inhabitants of LF types For example, we might want an M such that the following holds: M : ( append nil ( cons z nil ) ( cons z nil )) ◮ Notice that we already know the type to be well-formed here In the translation based approach, we would try to solve the query hastype M ( append nil ( cons z nil ) ( cons z nil )) using the clause ∀ L . ( hastype L list ) ⊃ ( hastype ( appNil L ) ( append nil L L ) However, this requires solving the redundant goal hastype ( cons z nil ) list Can we avoid such redundancies by simplifying the clause to ∀ L . hastype ( appNil L ) ( append nil L L )?

Improving the Translation The general question: When we can use the translation { { Π x : A . B } } := λ M . ∀ x . ( { { B } } ( M x ) without losing information? We have identified a sufficient condition for this purpose: ◮ x must appear in the target type of B ◮ It must have at least one occurrence which will not disappear after performing substitutions for other quantified variables ◮ If this occurrence is applied to arguments, they will not change the shape of any term substituted for x This condition, called strictness, can actually be improved to embody a recursive structure

A Translation-Based Implementation of Twelf ◮ The approach described here has been tested in the Parinati system that uses Teyjus to execute λ Prolog programs ◮ Experiments show that we can get up to an order of magnitude improvement in speed in comparison to an ML implementation ◮ Space conservation is even more dramatic: really large examples can be run without problem using our approach ◮ We are now implementing the system in a way that makes Teyjus an opaque backend to Twelf ◮ This implementation uses an inverse translation from simply typed λ -terms to LF expressions that we have developed

Conclusion We have developed the theoretical underpinnings for a translation from LF specifications to hohh specifications This translation has benefits at least for animating LF specification Future Work ◮ Realize a complete implementation of logic programming in Twelf based on the translation approach. ◮ Translate totality checking into Abella proofs. ◮ Reasoning directly using a dependently typed logic in an Abella-like system.