Mechanizing Metatheory with LF and Twelf

Transcription

1 Mechanizing Metatheory with LF and Twelf Robert Harper with Daniel R. Licata Carnegie Mellon University University of Oregon Summer School on Logic and Theorem Proving in Programming Languages July, 2008

2 Part I Overview

3 Representation of languages and logics in LF. What We ll Learn

4 What We ll Learn Representation of languages and logics in LF. Higher-Order Abstract Syntax (HOAS)

5 What We ll Learn Representation of languages and logics in LF. Higher-Order Abstract Syntax (HOAS) Judgements-as-Types Principle

6 What We ll Learn Representation of languages and logics in LF. Higher-Order Abstract Syntax (HOAS) Judgements-as-Types Principle Mechanization of metatheory using Twelf.

7 What We ll Learn Representation of languages and logics in LF. Higher-Order Abstract Syntax (HOAS) Judgements-as-Types Principle Mechanization of metatheory using Twelf. Relational Metathory.

8 What We ll Learn Representation of languages and logics in LF. Higher-Order Abstract Syntax (HOAS) Judgements-as-Types Principle Mechanization of metatheory using Twelf. Relational Metathory. Checking Coverage and Totality.

9 Format: How We ll Learn It

10 How We ll Learn It Format: Lectures on theory [Harper].

11 How We ll Learn It Format: Lectures on theory [Harper]. Laboratories using Twelf [Licata].

12 How We ll Learn It Format: Lectures on theory [Harper]. Laboratories using Twelf [Licata]. Readings:

13 How We ll Learn It Format: Lectures on theory [Harper]. Laboratories using Twelf [Licata]. Readings: Practical Foundations for Programming Languages.

14 How We ll Learn It Format: Lectures on theory [Harper]. Laboratories using Twelf [Licata]. Readings: Practical Foundations for Programming Languages. Mechanizing Metatheory in a Logical Framework.

15 How We ll Learn It Format: Lectures on theory [Harper]. Laboratories using Twelf [Licata]. Readings: Practical Foundations for Programming Languages. Mechanizing Metatheory in a Logical Framework. Twelf Wiki:

16 What is LF? LF is a logical framework, a general theory of abstract syntax.

17 What is LF? LF is a logical framework, a general theory of abstract syntax. Hierarchical structure (algebraic terms).

18 What is LF? LF is a logical framework, a general theory of abstract syntax. Hierarchical structure (algebraic terms). Binding and scope of identifiers.

19 What is LF? LF is a logical framework, a general theory of abstract syntax. Hierarchical structure (algebraic terms). Binding and scope of identifiers. Context-sensitive formation rules.

20 What is LF? LF is a logical framework, a general theory of abstract syntax. Hierarchical structure (algebraic terms). Binding and scope of identifiers. Context-sensitive formation rules. A language is inductively presented by a collection of generators, whose types are specified by a signature.

21 Simple Arithmetic Expressions The formation judgement e exp states that e is an arithmetic expression. This judgement is inductively defined by these two rules: n nat n exp e 1 exp e 2 exp e 1 + e 2 exp

22 Simple Arithmetic Expressions The formation judgement e exp states that e is an arithmetic expression. This judgement is inductively defined by these two rules: n nat n exp e 1 exp e 2 exp e 1 + e 2 exp The judgement e exp is the strongest (most restrictive) judgement closed under (obeying) these rules.

23 Abstract Syntax in LF Each rule becomes a generator in the LF signature.

24 Abstract Syntax in LF Each rule becomes a generator in the LF signature. Define abstract syntax of expressions. exp : type. num : nat -> exp. plus : exp -> exp -> exp.

25 Abstract Syntax in LF Each rule becomes a generator in the LF signature. Define natural numbers. nat : type. z : nat. s : nat -> nat. Define abstract syntax of expressions. exp : type. num : nat -> exp. plus : exp -> exp -> exp.

26 Simple Arithmetic Expressions Every arithmetic expression is uniquely represented by a closed LF term of LF type exp = plus (num (s (s z))) (num (s (s (s z)))). Moreover, every closed LF term of LF type exp represents a unique arithmetic expression.

27 Simple Arithmetic Expressions Every arithmetic expression is uniquely represented by a closed LF term of LF type exp = plus (num (s (s z))) (num (s (s (s z)))). Moreover, every closed LF term of LF type exp represents a unique arithmetic expression. These conditions express the adequacy of the representation of arithmetic expressions: e exp iff e : expr.

28 Evaluation Judgement The evaluation judgement e a states that the expression e evaluates to the answer a. It is defined by these rules: n n e 1 n 1 e 2 n 2 n = n 1 + n 2 e 1 + e 2 n It is the strongest judgement closed under these rules.

29 Judgements as Types The judgement is represented by a family of types: eval : exp -> ans -> type.

30 Judgements as Types Define the type of answers: ans : type. anat : nat -> ans. The judgement is represented by a family of types: eval : exp -> ans -> type.

31 Judgements as Types Define the type of answers: ans : type. anat : nat -> ans. The judgement is represented by a family of types: eval : exp -> ans -> type. The LF type eval e a represents derivations of e a. : e a iff : eval e a

32 Rules as Generators Each evaluation rule is represented by a generator: eval/num : eval (num N) (anum N). eval/plus : eval (plus E1 E2) (anum N) <- eval E1 (anum N1) <- eval E2 (anum N2) <- add N1 N2 N.

33 Rules as Generators Each evaluation rule is represented by a generator: eval/num : eval (num N) (anum N). eval/plus : eval (plus E1 E2) (anum N) <- eval E1 (anum N1) <- eval E2 (anum N2) <- add N1 N2 N. But what is meant by add?

34 Rules as Generators Must define addition on natural numbers as well: add : nat -> nat -> nat -> type. add/z : add z N N. add/s : add (s M) N (s P) <- add M N P.

35 Rules as Generators Must define addition on natural numbers as well: add : nat -> nat -> nat -> type. add/z : add z N N. add/s : add (s M) N (s P) <- add M N P. Adequacy: D : add m n p iff m + n = p.

36 Fully Explicit Form Eliminating abbreviations, and writing out parameters: eval/num : {N:nat} eval (num N) (anum N). eval/plus : {N:nat} {N1:nat} {N2:nat} {E1:exp} {E2:exp} add N1 N2 N -> eval E2 (anum N2) -> eval E1 (anum N1) -> eval (plus E1 E2) (anum N) Twelf takes care of all of this; you never have to write declarations in fully explicit form.

37 Mechanized Metatheory We can use Twelf to verify properties of representations. 1 Modes: functional dependencies in a type family (relation).

38 Mechanized Metatheory We can use Twelf to verify properties of representations. 1 Modes: functional dependencies in a type family (relation). 2 Coverage: all cases have been covered.

39 Mechanized Metatheory We can use Twelf to verify properties of representations. 1 Modes: functional dependencies in a type family (relation). 2 Coverage: all cases have been covered. 3 Termination: no circular definitions.

40 Mechanized Metatheory We can use Twelf to verify properties of representations. 1 Modes: functional dependencies in a type family (relation). 2 Coverage: all cases have been covered. 3 Termination: no circular definitions. Twelf can prove -type properties of representations. M 1 : A 1... M k : A k N 1 : B 1... N l : B l

41 Mechanized Metatheory We can use Twelf to verify properties of representations. 1 Modes: functional dependencies in a type family (relation). 2 Coverage: all cases have been covered. 3 Termination: no circular definitions. Twelf can prove -type properties of representations. M 1 : A 1... M k : A k N 1 : B 1... N l : B l This is sufficient for a large body of metareasoning!

42 Mode Checking Let s verify that add defines a total relation. add : nat -> nat -> nat -> type. add/z : add z N N. add/s : add (s M) N (s P) <- add M N P.

43 Mode Checking Let s verify that add defines a total relation. add : nat -> nat -> nat -> type. add/z : add z N N. add/s : add (s M) N (s P) <- add M N P. That is, M and N determine P in add M N P: add : nat -> nat -> nat -> type. %mode add +M +N -P. add/z : add z N N. add/s : add (s M) N (s P) <- add M N P.

44 Coverage and Termination To show that add M N P determines P, given M and N, we check 1 Coverage. There is a clause for every M. 2 Termination. There are no circular dependencies.

45 Coverage and Termination To show that add M N P determines P, given M and N, we check 1 Coverage. There is a clause for every M. 2 Termination. There are no circular dependencies. Twelf declarations: %worlds () (add ). %total M (add M ).

46 Coverage and Termination To show that add M N P determines P, given M and N, we check 1 Coverage. There is a clause for every M. 2 Termination. There are no circular dependencies. Twelf declarations: %worlds () (add ). %total M (add M ). Specifies that add is to be proved total on closed terms of type nat by structural induction on the first argument.

47 Mechanized Metatheory Twelf has verified that M, N : nat P : nat add M N P. This statement may be usefully re-phrased as M, N : nat P : nat D : add M N P.

48 Mechanized Metatheory Twelf has verified that M, N : nat P : nat add M N P. This statement may be usefully re-phrased as M, N : nat P : nat D : add M N P. Important: we may reason directly about derivations!

49 Evaluation Terminates We may just as easily prove that evaluation terminates! %worlds () (eval ). %total E (eval E ). That is, Twelf has proved E : exp A : ans D : eval E A This states termination of evaluation, by the adequacy of the representation.

50 Now enrich expressions with a binding construct: let x be e 1 in e 2 with the meaning that x stands for e 1 within e 2. Adding Bindings

51 Now enrich expressions with a binding construct: let x be e 1 in e 2 with the meaning that x stands for e 1 within e 2. Adding Bindings The variable x is bound within e 2. It serves as a pronoun referring to the binding site.

52 Now enrich expressions with a binding construct: Adding Bindings let x be e 1 in e 2 with the meaning that x stands for e 1 within e 2. The variable x is bound within e 2. It serves as a pronoun referring to the binding site. May be renamed, preserving pronoun structure: let x be 3 in x + x is let y be 3 in y + y.

53 Now enrich expressions with a binding construct: Adding Bindings let x be e 1 in e 2 with the meaning that x stands for e 1 within e 2. The variable x is bound within e 2. It serves as a pronoun referring to the binding site. May be renamed, preserving pronoun structure: let x be 3 in x + x is let y be 3 in y + y. May be substituted by an expression, preserving pronoun structure: [3/x](x + x) is

54 Adding Bindings Enrich expressions with a let-binding: e 1 exp x exp e 2 exp let x be e 1 in e 2 exp

55 Adding Bindings Enrich expressions with a let-binding: e 1 exp x exp e 2 exp let x be e 1 in e 2 exp The hypothetical judgement expresses binding structure:

56 Adding Bindings Enrich expressions with a let-binding: e 1 exp x exp e 2 exp let x be e 1 in e 2 exp The hypothetical judgement expresses binding structure:

57 Adding Bindings Enrich expressions with a let-binding: e 1 exp x exp e 2 exp let x be e 1 in e 2 exp The hypothetical judgement expresses binding structure: The variable x may occur within e 2.

58 Adding Bindings Enrich expressions with a let-binding: e 1 exp x exp e 2 exp let x be e 1 in e 2 exp The hypothetical judgement expresses binding structure: The variable x may occur within e 2. The name of the variable does not matter, only its referent.

59 Adding Bindings Enrich expressions with a let-binding: e 1 exp x exp e 2 exp let x be e 1 in e 2 exp The hypothetical judgement expresses binding structure: The variable x may occur within e 2. The name of the variable does not matter, only its referent. Substitution is valid: [e/x]e 2 exp whenever e exp.

60 Higher-Order Abstract Syntax The let construct is given by the declaration let : exp -> (exp -> exp) -> exp. Uses higher-order functions to express binding and scope!

61 Higher-Order Abstract Syntax The let construct is given by the declaration let : exp -> (exp -> exp) -> exp. Uses higher-order functions to express binding and scope! Representation: let x be e 1 in e 2 = let e 1 ([x:exp] e 2 ). where the λ-abstraction, [x:exp], expresses the binding and scope of x in e 2.

62 Higher-Order Abstract Syntax The let construct is given by the declaration let : exp -> (exp -> exp) -> exp. Uses higher-order functions to express binding and scope! Representation: let x be e 1 in e 2 = let e 1 ([x:exp] e 2 ). where the λ-abstraction, [x:exp], expresses the binding and scope of x in e 2.

63 Evaluation, Revisited Consider the rule for evaluation of a let: e 1 n 1 [n 1 /x]e 2 a let x be e 1 in e 2 a

64 Evaluation, Revisited Consider the rule for evaluation of a let: Formulated in LF: e 1 n 1 [n 1 /x]e 2 a let x be e 1 in e 2 a eval/let : eval (let E1 ([x] E2 x)) A <- eval E1 (anum N1) <- eval (E2 (num N1)) A.

65 Evaluation, Revisited Consider the rule for evaluation of a let: Formulated in LF: e 1 n 1 [n 1 /x]e 2 a let x be e 1 in e 2 a eval/let : eval (let E1 ([x] E2 x)) A <- eval E1 (anum N1) <- eval (E2 (num N1)) A. Substitution is provided for free by LF!

66 Enforcing Stronger Invariants We can track that variables are bound to values. val : type. num : nat -> val. exp : type. ret : val -> exp. plus : exp -> exp -> exp. let : exp -> (val -> exp) -> exp. As a rule it is good practice to use types to enforce invariants on a representation.

67 Higher-Order Rules We may use hypothetical judements to represent bindings: e 1 a 1 ret x a 1 e 2 a 2 let x be e 1 in e 2 a 2

68 Higher-Order Rules We may use hypothetical judements to represent bindings: e 1 a 1 ret x a 1 e 2 a 2 let x be e 1 in e 2 a 2 The evaluation hypothesis governs the variable x in e 2. ret x 3 (ret, x) + (ret 4) 7

69 Higher-Order Rules in LF Higher-order rules are represented using higher-order types: eval/let : eval (let E1 ([x] E2 x)) A <- eval E1 A1 <- ({x:val} eval (ret x) A1 -> eval (E2 x) A2).

70 Higher-Order Rules in LF Higher-order rules are represented using higher-order types: eval/let : eval (let E1 ([x] E2 x)) A <- eval E1 A1 <- ({x:val} eval (ret x) A1 -> eval (E2 x) A2). The general hypothetical judgement expresses that body is evaluated relative to

71 Higher-Order Rules in LF Higher-order rules are represented using higher-order types: eval/let : eval (let E1 ([x] E2 x)) A <- eval E1 A1 <- ({x:val} eval (ret x) A1 -> eval (E2 x) A2). The general hypothetical judgement expresses that body is evaluated relative to A fresh variable, x;

72 Higher-Order Rules in LF Higher-order rules are represented using higher-order types: eval/let : eval (let E1 ([x] E2 x)) A <- eval E1 A1 <- ({x:val} eval (ret x) A1 -> eval (E2 x) A2). The general hypothetical judgement expresses that body is evaluated relative to A fresh variable, x; A new axiom, stating that x evaluates to value of E1.

73 Higher-Order Rules The key to understanding higher-order rules is to understand the LF type theory.

74 Higher-Order Rules The key to understanding higher-order rules is to understand the LF type theory. The type A B consists of B s, possibly using a fresh axioms for A.

75 Higher-Order Rules The key to understanding higher-order rules is to understand the LF type theory. The type A B consists of B s, possibly using a fresh axioms for A. The type Π x:a B consists of B s with free variables x of type A in them.

76 Higher-Order Rules The key to understanding higher-order rules is to understand the LF type theory. The type A B consists of B s, possibly using a fresh axioms for A. The type Π x:a B consists of B s with free variables x of type A in them. LF types represent derivabilities, not admissibilities!

77 Higher-Order Rules The key to understanding higher-order rules is to understand the LF type theory. The type A B consists of B s, possibly using a fresh axioms for A. The type Π x:a B consists of B s with free variables x of type A in them. LF types represent derivabilities, not admissibilities! J 1 J 2 represented by J 1 J 2.

78 Higher-Order Rules The key to understanding higher-order rules is to understand the LF type theory. The type A B consists of B s, possibly using a fresh axioms for A. The type Π x:a B consists of B s with free variables x of type A in them. LF types represent derivabilities, not admissibilities! J 1 J 2 represented by J 1 J 2. x:a J represented by Π x: A J.

79 Adequacy and Worlds Adequacy of substitutive evaluation is relative to a closed world with no free derivation variables. : e a iff : eval e a.

80 Adequacy and Worlds Adequacy of substitutive evaluation is relative to a closed world with no free derivation variables. : e a iff : eval e a. This is expressed by the %worlds declaration: %worlds () (eval ). %total E (eval E ).

81 Adequacy and Worlds Adequacy of substitutive evaluation is relative to a closed world with no free derivation variables. : e a iff : eval e a. This is expressed by the %worlds declaration: %worlds () (eval ). %total E (eval E ). Adequacy for the higher-order formulation must consider derivations under hypotheses.

82 Adequacy and Worlds Higher-order evaluation introduces parameters and hypotheses during evaluation.

83 Adequacy and Worlds Higher-order evaluation introduces parameters and hypotheses during evaluation. Consider worlds (contexts) consisting of blocks of the form x : val, : eval (ret x) a. Adequacy is now stated relative to hypotheses represented by worlds: x 1 : val, : ret x 1 a 1,... a iff : eval (ret x 1 ) a 1, : eval e a

84 Adequacy and Worlds Worlds are declared in Twelf using %block and %worlds: %block eval block : some {A:ans} block {x:val} { :eval (ret x) A}. %worlds (eval block) (eval ). %total E (eval E ). These declarations check termination of the higher-order formulation of evaluation.

85 Typed Expressions Suppose we wished to extend the expression language with strings.

86 Typed Expressions Suppose we wished to extend the expression language with strings. We wish to impose context-sensitive constraints on formation of expressions. Cannot add a string and a number. Cannot concatenate two numbers.

87 Typed Expressions Suppose we wished to extend the expression language with strings. We wish to impose context-sensitive constraints on formation of expressions. Cannot add a string and a number. Cannot concatenate two numbers. This is achieved using a dependent type, which is a family of types indexed by some other type.

88 Typed Expressions Introduce an LF type of expression types. tp : type. number : tp. string : tp.

89 Typed Expressions Introduce an LF type of expression types. tp : type. number : tp. string : tp. Introduce an LF family of expressions of a type. exp : tp -> type. num : nat -> number exp. lit : str -> string exp. plus : number exp -> number exp -> number exp. append : string exp -> string exp -> string exp.

90 Typed Expressions Introduce an LF type of expression types. tp : type. number : tp. string : tp. Introduce an LF family of expressions of a type. exp : tp -> type. num : nat -> number exp. lit : str -> string exp. plus : number exp -> number exp -> number exp. append : string exp -> string exp -> string exp. (Must also define type str of strings.)

91 Typed Expressions Evaluation is defined exactly as before, but with types. ans : tp -> type. anum : nat -> ans. astr : str -> ans. eval : T exp -> T ans -> type.

92 Typed Expressions Evaluation is defined exactly as before, but with types. ans : tp -> type. anum : nat -> ans. astr : str -> ans. eval : T exp -> T ans -> type. The LF type of eval ensures preservation: the type of answer is of the same type as the expression being evaluated!

93 Typed Expressions Selected evaluation rules in LF: eval/num : eval (num N) (anum N). eval/lit : eval (lit S) (astr S). eval/plus : eval (plus E1 E2) (anum N) <- eval E1 (anum N1) <- eval E2 (anum N2) <- add N1 N2 N.

94 Typed Expressions Selected evaluation rules in LF: eval/num : eval (num N) (anum N). eval/lit : eval (lit S) (astr S). eval/plus : eval (plus E1 E2) (anum N) <- eval E1 (anum N1) <- eval E2 (anum N2) <- add N1 N2 N. No significant difference compared to untyped case.

95 Recap and Prospectus You ve now seen all of the basic features of LF and Twelf.

96 Recap and Prospectus You ve now seen all of the basic features of LF and Twelf. Signatures to define languages and logics.

97 Recap and Prospectus You ve now seen all of the basic features of LF and Twelf. Signatures to define languages and logics. Mode specifications and checking.

98 Recap and Prospectus You ve now seen all of the basic features of LF and Twelf. Signatures to define languages and logics. Mode specifications and checking. Coverage checking.

99 Recap and Prospectus You ve now seen all of the basic features of LF and Twelf. Signatures to define languages and logics. Mode specifications and checking. Coverage checking. Termination checking.

100 Recap and Prospectus You ve now seen all of the basic features of LF and Twelf. Signatures to define languages and logics. Mode specifications and checking. Coverage checking. Termination checking. Next we will cover the LF Type Theory in more detail.

101 Recap and Prospectus You ve now seen all of the basic features of LF and Twelf. Signatures to define languages and logics. Mode specifications and checking. Coverage checking. Termination checking. Next we will cover the LF Type Theory in more detail. Then we will develop a larger piece of metatheory, the type safety of MinML.

102 Part II Representation

103 Theory of Representation A formal system is represented fully, faithfull, and compositionally by LF canonical forms of specified type in specified worlds.

104 Theory of Representation A formal system is represented fully, faithfull, and compositionally by LF canonical forms of specified type in specified worlds. Full: every syntactic object o of class C has a unique representation o of type C.

105 Theory of Representation A formal system is represented fully, faithfull, and compositionally by LF canonical forms of specified type in specified worlds. Full: every syntactic object o of class C has a unique representation o of type C. Faithful: every canonical form of type C represents a unique syntactic object of class C.

106 Theory of Representation A formal system is represented fully, faithfull, and compositionally by LF canonical forms of specified type in specified worlds. Full: every syntactic object o of class C has a unique representation o of type C. Faithful: every canonical form of type C represents a unique syntactic object of class C. Compositional: representation commutes with substitution, [o 2 /x]o 1 = [ o 2 /x] o 1.

107 Theory of Representation A formal system is represented fully, faithfull, and compositionally by LF canonical forms of specified type in specified worlds. Full: every syntactic object o of class C has a unique representation o of type C. Faithful: every canonical form of type C represents a unique syntactic object of class C. Compositional: representation commutes with substitution, [o 2 /x]o 1 = [ o 2 /x] o 1. Let us now make these ideas precise.

108 The LF Type Theory LF is a dependently typed λ-calculus with two levels:

109 The LF Type Theory LF is a dependently typed λ-calculus with two levels: Families, A, classified by Kinds, K.

110 The LF Type Theory LF is a dependently typed λ-calculus with two levels: Families, A, classified by Kinds, K. Objects, M, classified by Types, A.

111 The LF Type Theory LF is a dependently typed λ-calculus with two levels: Families, A, classified by Kinds, K. Objects, M, classified by Types, A. The syntax is classified into levels: Kind Family Canonical Object Atomic Object K ::= type Π x:a K A ::= a A M Π x:a B M ::= R λ x:a M R ::= x c R M

112 The LF Type Theory Intuitively, canonical objects are long βη-normal forms.

113 The LF Type Theory Intuitively, canonical objects are long βη-normal forms. No β-redices: λ x:a M N.

114 The LF Type Theory Intuitively, canonical objects are long βη-normal forms. No β-redices: λ x:a M N. Fully η-expanded: λ x:a y x, not y, if y : Π x:a B.

115 The LF Type Theory Intuitively, canonical objects are long βη-normal forms. No β-redices: λ x:a M N. Fully η-expanded: λ x:a y x, not y, if y : Π x:a B. Formally, these classes are inductively defined without reduction or expansion.

116 The LF Type Theory Intuitively, canonical objects are long βη-normal forms. No β-redices: λ x:a M N. Fully η-expanded: λ x:a y x, not y, if y : Π x:a B. Formally, these classes are inductively defined without reduction or expansion. Predicativity (clean living) makes this possible.

117 The LF Type Theory Intuitively, canonical objects are long βη-normal forms. No β-redices: λ x:a M N. Fully η-expanded: λ x:a y x, not y, if y : Π x:a B. Formally, these classes are inductively defined without reduction or expansion. Predicativity (clean living) makes this possible. Never have to worry about non-canonical objects interfering with representation.

118 The LF Type Theory Intuitively, canonical objects are long βη-normal forms. No β-redices: λ x:a M N. Fully η-expanded: λ x:a y x, not y, if y : Π x:a B. Formally, these classes are inductively defined without reduction or expansion. Predicativity (clean living) makes this possible. Never have to worry about non-canonical objects interfering with representation. But substitution must be defined to preserve canonical and atomic forms!

119 The LF Type Theory An LF context, Γ, is a sequence of variable declarations: x 1 : A 1,..., x n : A n wherein each A i may involve the preceding variables.

120 The LF Type Theory An LF context, Γ, is a sequence of variable declarations: x 1 : A 1,..., x n : A n wherein each A i may involve the preceding variables. An LF signature, Σ, is a sequence of constant declarations: { } { } a1 : K 1 am : K m,..., c 1 : A 1 c m : A m where each A i or K i may involve the preceding constants.

121 The LF Type Theory Formation judgements of LF: Γ Σ K kind Γ Σ A K Γ Σ M A Σ Γ ok Γ Σ R A Σ ok Canonical objects are analyzed, atomic objects are synthesized.

122 The LF Type Theory Substitution judgements of LF: [M/x]K = K [M/x]A = A [M/x]N = N [M/x]R = M

123 The LF Type Theory Substitution judgements of LF: [M/x]K = K [M/x]A = A [M/x]N = N [M/x]R = M The critical case threatens termination: [λ y:a M/x](x N) = [N/y]M

124 The LF Type Theory Substitution judgements of LF: [M/x]K = K [M/x]A = A [M/x]N = N [M/x]R = M The critical case threatens termination: [λ y:a M/x](x N) = [N/y]M But the erased type (dependency-free simple type) of the substituting object gets smaller!

125 Atomic Objects Variables and constants: Γ Σ1,c:A,Σ 2 c A Γ 1, x : A, Γ 2 Σ x A

126 Atomic Objects Variables and constants: Γ Σ1,c:A,Σ 2 c A Γ 1, x : A, Γ 2 Σ x A Function application: Γ Σ R Π x:a1 A 2 Γ Σ M A 1 [M/x]A 2 = A Γ Σ R M A

127 Canonical Objects Atomic objects of base type are canonical: Γ Σ R A A Π x:a1 A 2 Γ Σ R A

128 Canonical Objects Atomic objects of base type are canonical: Γ Σ R A A Π x:a1 A 2 Γ Σ R A Abstractions are canonical at higher type: Γ, x : A 1 Σ M A 2 Γ Σ λ x:a1 M 2 Π x:a1 A 2

129 Type Families Constants: Γ Σ1,a:K,Σ 2 a K

130 Type Families Constants: Γ Σ1,a:K,Σ 2 a K Family instantiation: Γ Σ A Π x:a1 K 2 Γ Σ M A 1 [M/x]K 2 = K Γ Σ A M K

131 Type Families Products of families: Γ Σ A 1 type Γ, x : A 1 Σ A 2 type Γ Σ Π x:a1 A 2 type

132 Kinds The kind of types: Γ Σ type kind

133 Kinds The kind of types: Product of a kind family: Γ Σ type kind Γ Σ A 1 type Γ, x : A 1 Σ K 2 kind Γ Σ Π x:a1 K 2 kind

134 Central principle: capture entailments. Representation Methodology

135 Representation Methodology Central principle: capture entailments. Syntactic: variables and substitution (general judgement).

136 Representation Methodology Central principle: capture entailments. Syntactic: variables and substitution (general judgement). Deductive: derivability consequence relation (hypothetical judgement).

137 Representation Methodology Central principle: capture entailments. Syntactic: variables and substitution (general judgement). Deductive: derivability consequence relation (hypothetical judgement). A lesson of LF is that there is no real distinction between the syntactic and the deductive.

138 Representation Methodology Central principle: capture entailments. Syntactic: variables and substitution (general judgement). Deductive: derivability consequence relation (hypothetical judgement). A lesson of LF is that there is no real distinction between the syntactic and the deductive. Advice: represent as wide a class of entailments as possible, to maximize utility and generality.

139 Representation Methodology Syntactic classes for arithmetic expressions: v val values

140 Representation Methodology Syntactic classes for arithmetic expressions: v val values e exp expressions

141 Representation Methodology Syntactic classes for arithmetic expressions: v val values e exp expressions a ans answers

142 Representation Methodology Syntactic classes for arithmetic expressions: v val values e exp expressions a ans answers e a derivations of evaluations

143 Representation Methodology Syntactic classes for arithmetic expressions: v val values e exp expressions a ans answers e a derivations of evaluations Entailments for arithmetic expressions: x val v val values with value variables

144 Representation Methodology Syntactic classes for arithmetic expressions: v val values e exp expressions a ans answers e a derivations of evaluations Entailments for arithmetic expressions: x val v val values with value variables x val e exp expressions with value variables

145 Representation Methodology Syntactic classes for arithmetic expressions: v val values e exp expressions a ans answers e a derivations of evaluations Entailments for arithmetic expressions: x val v val values with value variables x val e exp expressions with value variables a ans closed answers

146 Representation Methodology Syntactic classes for arithmetic expressions: v val values e exp expressions a ans answers e a derivations of evaluations Entailments for arithmetic expressions: x val v val values with value variables x val e exp expressions with value variables a ans closed answers e a closed evaluations

147 Representation Methodology Embed object-language entailments as LF entailments: x 1 val,..., x k val v val x 1 : val,..., x k : val Σ v val

148 Representation Methodology Embed object-language entailments as LF entailments: x 1 val,..., x k val v val x 1 : val,..., x k : val Σ v val x 1 val,..., x k val e exp x 1 : val,..., x k : val Σ e exp

149 Adequacy of Representations Check that embeddings are compositional, i.e., commute with substitution: if x val v val and v val, then [v/x]v = [ v /x] v. if x val e val and v val, then [v/x]e = [ v /x] e.

150 Adequacy of Representations Check that embeddings are compositional, i.e., commute with substitution: if x val v val and v val, then [v/x]v = [ v /x] v. if x val e val and v val, then [v/x]e = [ v /x] e. Equivalently, check that object language entailments are fully and faithfully embedded in framework entailment.

151 Adequacy of Representations Embedding for higher-order representation of evaluation: x 1 : val, x 1 val, ret(x 1 ) a 1, e a : eval (ret x 1 ) a 1, Σ eval e a

152 Adequacy of Representations Embedding for higher-order representation of evaluation: x 1 : val, x 1 val, ret(x 1 ) a 1, e a : eval (ret x 1 ) a 1, Σ eval e a Compositionality means that evaluation under assumptions is faithfully represented.

153 Consequences of Adequacy An adequate representation obviates the object language itself!

154 Consequences of Adequacy An adequate representation obviates the object language itself! That is, the object language exists solely as embedded in LF; all other representations are nugatory.

155 Consequences of Adequacy An adequate representation obviates the object language itself! That is, the object language exists solely as embedded in LF; all other representations are nugatory. Representation in LF becomes normative for representations of object languages.

156 Consequences of Adequacy An adequate representation obviates the object language itself! That is, the object language exists solely as embedded in LF; all other representations are nugatory. Representation in LF becomes normative for representations of object languages. Experience has shown that it improves our understanding of an object language to formalize it in LF.

157 From Adequacy to Metatheory Recall: a world is a class of LF contexts. (Twelf worlds are given as series of blocks.)

158 From Adequacy to Metatheory Recall: a world is a class of LF contexts. (Twelf worlds are given as series of blocks.) Adequacy is always relative to a specified world.

159 From Adequacy to Metatheory Recall: a world is a class of LF contexts. (Twelf worlds are given as series of blocks.) Adequacy is always relative to a specified world. The syntax of a language arises as the atomic objects of certain types in specified worlds. (Perhaps a different world for each type).

160 From Adequacy to Metatheory Recall: a world is a class of LF contexts. (Twelf worlds are given as series of blocks.) Adequacy is always relative to a specified world. The syntax of a language arises as the atomic objects of certain types in specified worlds. (Perhaps a different world for each type). Mechanized metatheory reduces to structural induction over the canonical forms of a specified type in a specified world. (Modulo α-equivalence, i.e., renaming of bound variables.)

161 Part III Mechanized Metatheory

162 Metatheory With Twelf Much standard meta-theory is easily mechanized using Twelf. Determinacy of evaluation. We will consider type safety for a small language. But:

163 Metatheory With Twelf Much standard meta-theory is easily mechanized using Twelf. Determinacy of evaluation. Decidability of type checking. We will consider type safety for a small language. But:

164 Metatheory With Twelf Much standard meta-theory is easily mechanized using Twelf. Determinacy of evaluation. Decidability of type checking. Structural properties such as weakening or substitution. We will consider type safety for a small language. But:

165 Metatheory With Twelf Much standard meta-theory is easily mechanized using Twelf. Determinacy of evaluation. Decidability of type checking. Structural properties such as weakening or substitution. Cut elimination for a logic. We will consider type safety for a small language. But:

166 Metatheory With Twelf Much standard meta-theory is easily mechanized using Twelf. Determinacy of evaluation. Decidability of type checking. Structural properties such as weakening or substitution. Cut elimination for a logic. Safety of compiler transformations. We will consider type safety for a small language. But:

167 Metatheory With Twelf Much standard meta-theory is easily mechanized using Twelf. Determinacy of evaluation. Decidability of type checking. Structural properties such as weakening or substitution. Cut elimination for a logic. Safety of compiler transformations. We will consider type safety for a small language. But: Scales to serious languages such as Standard ML.

168 Metatheory With Twelf Much standard meta-theory is easily mechanized using Twelf. Determinacy of evaluation. Decidability of type checking. Structural properties such as weakening or substitution. Cut elimination for a logic. Safety of compiler transformations. We will consider type safety for a small language. But: Scales to serious languages such as Standard ML. Useful for much more than just type safety.

169 A MinML Fragment of ML Abstract syntax: tp : type. nat : tp. arr : tp -> tp -> tp. exp : tp -> type. z : nat exp. s : nat exp -> nat exp. ifz : nat exp -> T exp -> (nat exp -> T exp) -> T exp. (Conditional passes predecessor to non-zero case.)

170 A MinML Fragment of ML Abstract syntax, cont d: fun : {T1:tp} {T2:tp} ((arr T1 T2) exp -> T1 exp -> T2 exp) -> (arr T1 T2) exp. app : (arr T1 T2) exp -> T1 exp -> T2 exp. (Functions are self-referential to support recursion.)

171 Dynamic Semantics of MinML Values of a type: value : T exp -> type. % mode value +E.

172 Dynamic Semantics of MinML Values of a type: value : T exp -> type. % mode value +E. value/z : value z.

173 Dynamic Semantics of MinML Values of a type: value : T exp -> type. % mode value +E. value/z : value z. value/s : value (s E) <- value E.

174 Dynamic Semantics of MinML Values of a type: value : T exp -> type. % mode value +E. value/z : value z. value/s : value (s E) <- value E. value/fun : value (fun ).

175 Dynamic Semantics of MinML Structural operational semantics: step : T exp -> T exp -> type. % mode step +E1 -E2.

176 Dynamic Semantics of MinML Structural operational semantics: step : T exp -> T exp -> type. % mode step +E1 -E2. step/s : step (s E) (s E ) <- step E E.

177 Dynamic Semantics of MinML Structural operational semantics: step : T exp -> T exp -> type. % mode step +E1 -E2. step/s : step (s E) (s E ) <- step E E. step/ifz/arg : step (ifz E E1 ([x] E2 x)) (ifz E E1 ([x] E2 x)) <- step E E.

178 Dynamic Semantics of MinML Structural operational semantics: step : T exp -> T exp -> type. % mode step +E1 -E2. step/s : step (s E) (s E ) <- step E E. step/ifz/arg : step (ifz E E1 ([x] E2 x)) (ifz E E1 ([x] E2 x)) <- step E E. step/ifz/z : step (ifz z E1 ([x] E2 x)) E1.

179 Dynamic Semantics of MinML Structural operational semantics: step : T exp -> T exp -> type. % mode step +E1 -E2. step/s : step (s E) (s E ) <- step E E. step/ifz/arg : step (ifz E E1 ([x] E2 x)) (ifz E E1 ([x] E2 x)) <- step E E. step/ifz/z : step (ifz z E1 ([x] E2 x)) E1. step/ifz/s : step (ifz (s E) E1 ([x] E2 x)) (E2 E) <- value E.

180 Dynamic Semantics of MinML Structural operational semantics, cont d: step/app/fun : step (app E1 E2) (app E1 E2) <- step E1 E1.

181 Dynamic Semantics of MinML Structural operational semantics, cont d: step/app/fun : step (app E1 E2) (app E1 E2) <- step E1 E1. step/app/arg : step (app E1 E2) (app E1 E2 ) <- value E1 <- step E2 E2.

182 Dynamic Semantics of MinML Structural operational semantics, cont d: step/app/fun : step (app E1 E2) (app E1 E2) <- step E1 E1. step/app/arg : step (app E1 E2) (app E1 E2 ) <- value E1 <- step E2 E2. step/app/beta-v : step (app (fun T1 T2 ([f] [x] E f x)) E2) (E (fun T1 T2 ([f] [x] E f x)) E2) <- value E2.

183 Proving Metatheorems With Twelf We used Twelf to prove that evaluation terminates: eval : T exp -> T val -> type. %mode eval +E -V.... %worlds () (eval ). %total D (eval D ).

184 Proving Metatheorems With Twelf We used Twelf to prove that evaluation terminates: eval : T exp -> T val -> type. %mode eval +E -V.... %worlds () (eval ). %total D (eval D ). We will use the same method to verify metatheorems!

185 Proving Metatheorems With Twelf Progress Theorem: if e : τ, then either e value, or there exists e such that e e.

186 Proving Metatheorems With Twelf Progress Theorem: if e : τ, then either e value, or there exists e such that e e. A constructive proof of progress defines a transformation that sends a derivation of e : τ into either a derivation of e value or a derivation of e e for some e.

187 Proving Metatheorems With Twelf Progress Theorem: if e : τ, then either e value, or there exists e such that e e. A constructive proof of progress defines a transformation that sends a derivation of e : τ into either a derivation of e value or a derivation of e e for some e. We define this transformation as a relation, then show that it is total to prove the theorem.

188 Proving Metatheorems With Twelf Progress Theorem: if e : τ, then either e value, or there exists e such that e e. A constructive proof of progress defines a transformation that sends a derivation of e : τ into either a derivation of e value or a derivation of e e for some e. We define this transformation as a relation, then show that it is total to prove the theorem. The content of the proof is a dependently typed program that performs the transformation and is defined for all inputs.

189 Metatheory of MinML The intrinsic representation guarantees type preservation: step : T exp -> T exp -> type.

190 Metatheory of MinML The intrinsic representation guarantees type preservation: step : T exp -> T exp -> type. Progress: if E : T exp, then either value E or steps E E.

191 Metatheory of MinML The intrinsic representation guarantees type preservation: step : T exp -> T exp -> type. Progress: if E : T exp, then either value E or steps E E. Progress, re-formulated: for every object E : T exp, either there exists an object Dv of type val E, or there exists an object Ds of type steps E E.

192 Metatheory of MinML The intrinsic representation guarantees type preservation: step : T exp -> T exp -> type. Progress: if E : T exp, then either value E or steps E E. Progress, re-formulated: for every object E : T exp, either there exists an object Dv of type val E, or there exists an object Ds of type steps E E. Progress, re-re-formulated: for every object E:T exp, there exists an object D of type val-or-step E.

193 Progress Theorem Define val-or-step judgement: val-or-step : T exp -> type.

194 Progress Theorem Define val-or-step judgement: val-or-step : T exp -> type. vos/val : val-or-step E <- value E.

195 Progress Theorem Define val-or-step judgement: val-or-step : T exp -> type. vos/val : val-or-step E <- value E. vos/step : val-or-step E <- step E.

196 Progress Theorem Define val-or-step judgement: val-or-step : T exp -> type. vos/val : val-or-step E <- value E. vos/step : val-or-step E <- step E. State progress theorem relationally: prog : {E : T exp} val-or-step E -> type. % mode prog +E -Dvos.

197 Progress Theorem Define val-or-step judgement: val-or-step : T exp -> type. vos/val : val-or-step E <- value E. vos/step : val-or-step E <- step E. State progress theorem relationally: prog : {E : T exp} val-or-step E -> type. % mode prog +E -Dvos. Thus prog E D relates E : T exp to D : val-or-step E.

198 Progress Theorem Axiomatize the progress relation: - : prog z (vos/val value/z).

199 Progress Theorem Axiomatize the progress relation: - : prog z (vos/val value/z). - : prog (s E) Dvos <- prog E Dvos <- prog/s Dvos Dvos.

200 Progress Theorem Axiomatize the progress relation: - : prog z (vos/val value/z). - : prog (s E) Dvos <- prog E Dvos <- prog/s Dvos Dvos. - : prog (ifz E E1 ([x] E2 x)) (vos/step Dstep) <- prog E Dvos <- prog/ifz Dvos Dstep.

201 Progress Theorem Axiomatize the progress relation, cont d: - : prog (fun ) (vos/val value/fun).

202 Progress Theorem Axiomatize the progress relation, cont d: - : prog (fun ) (vos/val value/fun). - : prog (app E1 E2) (vos/step Dstep) <- prog E1 Dvos1 <- prog E2 Dvos2 <- prog/app Dvos1 Dvos2 Dstep.

203 Progress Theorem Axiomatize the progress relation, cont d: - : prog (fun ) (vos/val value/fun). - : prog (app E1 E2) (vos/step Dstep) <- prog E1 Dvos1 <- prog E2 Dvos2 <- prog/app Dvos1 Dvos2 Dstep. Prove the theorem: %worlds () (prog ). %total Dof (prog Dof ).

204 Progress Theorem To quote Paul Taylor, Theorems, like management, get all the credit, but the lemmas do all the work.

205 Progress Theorem To quote Paul Taylor, Theorems, like management, get all the credit, but the lemmas do all the work. We have reduced progress to three lemmas.

206 Progress Theorem To quote Paul Taylor, Theorems, like management, get all the credit, but the lemmas do all the work. We have reduced progress to three lemmas. If either value E0 or stepsto E0 E0, then

207 Progress Theorem To quote Paul Taylor, Theorems, like management, get all the credit, but the lemmas do all the work. We have reduced progress to three lemmas. If either value E0 or stepsto E0 E0, then 1 either value (s E0) or stepsto (s E0) (s E0 );

208 Progress Theorem To quote Paul Taylor, Theorems, like management, get all the credit, but the lemmas do all the work. We have reduced progress to three lemmas. If either value E0 or stepsto E0 E0, then 1 either value (s E0) or stepsto (s E0) (s E0 ); 2 stepsto (ifz E0 E1 ([x] E2 x)) E ;

209 Progress Theorem To quote Paul Taylor, Theorems, like management, get all the credit, but the lemmas do all the work. We have reduced progress to three lemmas. If either value E0 or stepsto E0 E0, then 1 either value (s E0) or stepsto (s E0) (s E0 ); 2 stepsto (ifz E0 E1 ([x] E2 x)) E ; 3 if value E1 or stepsto E1 E1, then stepsto (app E0 E1) E.

210 Progress Lemma: Successor prog/s : val-or-step E -> val-or-step (s E) -> type. % mode prog/s +Dvos1 -Dvos2.

211 Progress Lemma: Successor prog/s : val-or-step E -> val-or-step (s E) -> type. % mode prog/s +Dvos1 -Dvos2. - : prog/s (vos/step Dstep) (vos/step (step/s Dstep)).

212 Progress Lemma: Successor prog/s : val-or-step E -> val-or-step (s E) -> type. % mode prog/s +Dvos1 -Dvos2. - : prog/s (vos/step Dstep) (vos/step (step/s Dstep)). - : prog/s (vos/val Dval) (vos/val (value/s Dval)).

213 Progress Lemma: Successor prog/s : val-or-step E -> val-or-step (s E) -> type. % mode prog/s +Dvos1 -Dvos2. - : prog/s (vos/step Dstep) (vos/step (step/s Dstep)). - : prog/s (vos/val Dval) (vos/val (value/s Dval)). % worlds () (prog/s ). % total (prog/s ).

214 Progress Lemma: Conditional prog/ifz : val-or-step (E : nat exp) -> {E1} {E2} (step (ifz E E1 ([x] E2 x)) E ) -> type. %mode prog/ifz +E +E1 +E2 -Dstep.

215 Progress Lemma: Conditional prog/ifz : val-or-step (E : nat exp) -> {E1} {E2} (step (ifz E E1 ([x] E2 x)) E ) -> type. %mode prog/ifz +E +E1 +E2 -Dstep. - : prog/ifz (vos/step Dstep) (step/ifz/arg Dstep).

216 Progress Lemma: Conditional prog/ifz : val-or-step (E : nat exp) -> {E1} {E2} (step (ifz E E1 ([x] E2 x)) E ) -> type. %mode prog/ifz +E +E1 +E2 -Dstep. - : prog/ifz (vos/step Dstep) (step/ifz/arg Dstep). - : prog/ifz (vos/val value/z) step/ifz/z.

217 Progress Lemma: Conditional prog/ifz : val-or-step (E : nat exp) -> {E1} {E2} (step (ifz E E1 ([x] E2 x)) E ) -> type. %mode prog/ifz +E +E1 +E2 -Dstep. - : prog/ifz (vos/step Dstep) (step/ifz/arg Dstep). - : prog/ifz (vos/val value/z) step/ifz/z. - : prog/ifz (vos/val (value/s Dval)) (step/ifz/s Dval).

218 Progress Lemma: Conditional prog/ifz : val-or-step (E : nat exp) -> {E1} {E2} (step (ifz E E1 ([x] E2 x)) E ) -> type. %mode prog/ifz +E +E1 +E2 -Dstep. - : prog/ifz (vos/step Dstep) (step/ifz/arg Dstep). - : prog/ifz (vos/val value/z) step/ifz/z. - : prog/ifz (vos/val (value/s Dval)) (step/ifz/s Dval). %worlds () (prog/ifz ). %total (prog/ifz ).

219 Progress Lemma: Application prog/app : val-or-step (E1 : (arr T2 T) exp) -> val-or-step (E2 : T2 exp) -> step (app E1 E2) E -> type. %mode prog/app +Dvos1 +Dvos2 -Dstep.

220 Progress Lemma: Application prog/app : val-or-step (E1 : (arr T2 T) exp) -> val-or-step (E2 : T2 exp) -> step (app E1 E2) E -> type. %mode prog/app +Dvos1 +Dvos2 -Dstep. - : prog/app (vos/step Dstep1) (step/app/fun Dstep1).

221 Progress Lemma: Application - : prog/app (vos/val Dval1) (vos/step Dstep2) (step/app/arg Dstep2 Dval1).

222 Progress Lemma: Application - : prog/app (vos/val Dval1) (vos/step Dstep2) (step/app/arg Dstep2 Dval1). - : prog/app (vos/val Dval1) (vos/val Dval2) (step/app/beta-v Dval2).

223 Progress Lemma: Application - : prog/app (vos/val Dval1) (vos/step Dstep2) (step/app/arg Dstep2 Dval1). - : prog/app (vos/val Dval1) (vos/val Dval2) (step/app/beta-v Dval2). %worlds () (prog/app ). %total (prog/app ).

224 Where From Here? Twelf is in daily use as a tool for language design and implementation. Natural pattern-driven, dependently typed programming with direct support for structural features of languages and logics.

225 Where From Here? Twelf is in daily use as a tool for language design and implementation. Natural pattern-driven, dependently typed programming with direct support for structural features of languages and logics. Readable and maintainable proofs, not proof scripts.

226 Where From Here? Twelf is in daily use as a tool for language design and implementation. Natural pattern-driven, dependently typed programming with direct support for structural features of languages and logics. Readable and maintainable proofs, not proof scripts. Imposes healthy reality and sanity check on language designs.

227 Where From Here? Twelf is in daily use as a tool for language design and implementation. Natural pattern-driven, dependently typed programming with direct support for structural features of languages and logics. Readable and maintainable proofs, not proof scripts. Imposes healthy reality and sanity check on language designs. Exposes, and helps correct, subtle design errors early in the process. (Greatly diminishes POPL deadline anxiety!) Try it, you ll like it!