From proof theory to HCI. . . and back again James McKinna Roy - PowerPoint PPT Presentation

From proof theory to HCI. . . and back again James McKinna Roy Dyckhoff Celebration St. Andrews 2011-11-19

part I: from proof theory to HCI ◮ from Coquand to LEGO/Coq (tactic-driven) ◮ from Martin-Löf to ALF (direct-style proof editing) ◮ from Gentzen to MacLogic (push button tactics) insights: Pym, Herbelin, Dyckhoff-Pinto

MacLogic MacLogic was developed specifically for the Apple Macintosh, which has consistently had an excellent user interface. If you want a similar tool for another kind of computer, please look elsewhere. http://www.cs.st-andrews.ac.uk/˜rd/logic/mac

MacLogic this slide (un)intentionally left blank

tensions ◮ research problems vs. didactic solutions ◮ research tools vs. teaching tools ◮ difficulty of instrumentation vs. accessibility to users

proof search a pervasive theme in Roy’s work ◮ theoretical: ◮ admissibility ◮ termination ◮ completeness ◮ practical: to solve problems to which the user should remain oblivious ◮ actual: use Maple to find polynomials for termination orderings!

“we know a proof when we see one” (Kreisel) fundamental property: explain deduction of a formula A via a typed term calculus Γ ⊢ M : A such that ◮ typing judgment Γ ⊢ M : A is decidable ◮ by reduction to type synthesis Γ ⊢ M ⇒ B ◮ and type conversion Γ ⊢ B ≃ A idea: to compute B , look at structure of M ! modern version: bidirectional typechecking, mixing synthesis and checking Γ ⊢ M ⇐ A

a perspective on programming insight via Curry/Howard/deBruijn: ◮ programming (as an activity) is the user’s solution to the type inhabitation problem Γ ⊢ ? : A ◮ . . . which is just proof search ◮ . . . with certain obvious heuristics (Dowek; Miller) so: consider HCI of programming from the perspective of proof search, with an eye to HCI of (interactive) theorem proving

cognitive dimensions (Green et al., 1989 et seq.) a heuristic framework for evaluating notations (programming languages, but also the language of user interfaces) ◮ theoretical: descriptive “balance of forces”, trade-offs ◮ practical: diagnostic among others: ◮ premature commitment ◮ viscosity vs. abstraction ◮ hard mental operations (sic)

proof search in type theory classical approach to premature commitment in proof search in natural deduction (NJ): use sequent calculus (LJ)! ◮ source of premature commitment: choice of antecedent formula in → -elim ◮ solution: left-/right rules (LJ), rather than intro-/elim- rules (NJ) ◮ a calculus for inhabitation of corresponding NJ formulas-as-types ◮ unification/meta-variables delay choice of term witnesses to ∀ -left instances Lots of literature, esp. now on extensions to dependent types Almost none on using this for programming

part II: . . . and back again

basic tenet to seek a language of interaction more faithful to the human’s (primitive) intentions/actions ◮ abstraction (more generally: right rules) ◮ hypothesis selection (focus) ◮ suitable matching against a goal (unification)

my interest ◮ a return to the design space of potential DTP , revisiting Epigram 1 (2004) and PTSC (2006/2011) ◮ some extensions/generalisations: ◮ modest extensions to E PIGRAM 1-style intended to reduce premature commitment ◮ re-designing type theory in sequent calculus style to support postponed decisions

E PIGRAM 1: use the programmer to control search programmer chooses: ◮ left-hand sides: ‘case analysis’ ( ⇐ ) ◮ recursion schemes: identify allowable recursive calls (also ⇐ !) ◮ right-hand sides: solutions to ‘leaf’ problems ( ⇒ ) ◮ intermediate computation ( � , not ‘let’ as such) Each amounts to supplying (sufficient) evidence to solve the corresponding problem. Informal justification by appeal to left-/right-rules in sequent calculus ; ‘with’ is cut ) Problem every program begins with commitment to some rec !

Type Theory in Sequent Calculus style (CSL 2006) a term calculus with two judgment forms: ◮ Γ ⊢ M : A corresponding to Γ ⊢ ? : A ◮ Γ; A ⊢ l : B corresponding to computing argument lists to “match” A against B Key idea: LJ is too permissive, so tighten up to remove inessential variation (permutation of rules) → ∗ Π x A . B D − Γ ⊢ PS M : A Γ | � M / x � B ⊢ PS l : C Π l Γ | D ⊢ PS M · l : C Can see this as a rational reconstruction of Refine in L EGO , Apply in C OQ

Adding meta-variables (LMCS 2011) leads to a calculus in which ◮ Dowek’s complete semi-recursive type inhabitation procedure can be recovered, hence higher-order unification Challenge extend analysis to datatypes , thereby ◮ making solid the E PIGRAM 1/sequent calculus informal connection ◮ modernising, to deal with e.g. bidirectional type checking, . . .

Rules, I Γ ⊢ ⊢ ⊢ PE M : A | Σ Γ = x 1 : A 1 , . . . , x n : A n Claim α Γ ⊢ ⊢ ⊢ PE α ( x 1 [] , . . . , x n []): C | (Γ ⊢ ⊢ ⊢ α : C ) ( x : A ) ∈ Γ Γ; A ⊢ ⊢ PE l : C | Σ ⊢ Select x Γ ⊢ ⊢ ⊢ PE x l : C | Σ → ∗ Bx Π x A . B C − Γ , x : A ⊢ ⊢ ⊢ PE M : B | Σ Π r ⊢ PE λ x A . M : C | Σ ⊢ Γ ⊢

Rules, II Γ; B ⊢ ⊢ ⊢ PE l : C | Σ Γ = x 1 : A 1 , . . . , x n : A n Claim β ⊢ ⊢ Γ; D ⊢ ⊢ PE β ( x 1 [] , . . . , x n []): C | (Γ; D ⊢ ⊢ β : C ) axiom ⊢ PE []: C | D Γ Γ; D ⊢ ⊢ = C Bx Π x A . B ⊢ ⊢ D − → ∗ Γ ⊢ ⊢ PE M : A | Σ 1 Γ; � M / x � B ⊢ ⊢ PE l : C | Σ 2 Π l Γ; D ⊢ ⊢ ⊢ PE M · l : C | Σ 1 , Σ 2

Rules, III Σ = ⇒ PE σ ⊢ PE l : C | Σ ′′ Σ , Σ ′′ , ( β �→ Dom (Γ) . l )(Σ ′ ) = Γ; B ⊢ ⊢ ⇒ PE σ Σ , σ Σ ′′ , σ Σ ′ Solve β ⊢ β : C ) , Σ ′ = Σ , (Γ; B ⊢ ⊢ ⇒ PE σ Σ , ( β �→ Dom (Γ) . ( σ Σ , σ Σ ′′ )( l )) , σ Σ ′ ⊢ ⊢ PE M : A | Σ ′′ Σ , Σ ′′ , ( α �→ Dom (Γ) . M )(Σ ′ ) = Γ ⊢ ⇒ PE σ Σ , σ Σ ′′ , σ Σ ′ Solve α ⊢ α : A ) , Σ ′ = Σ , (Γ ⊢ ⊢ ⇒ PE σ Σ , ( α �→ Dom (Γ) . ( σ Σ , σ Σ ′′ )( M )) , σ Σ ′ Σ is solved Solved Σ = ⇒ PE ∅

Advantages for the implementor? Such calculi combine ◮ explicit substitutions ◮ spine representations so hopefully better adapted towards ◮ abstract machines for evaluation ◮ ‘internal’ (inferential mode) and ‘external’ (checking mode) Metavariables and unification/conversion are baked in from the start, so there is no separate ‘program construction’ layer distinct from that of eventually elaborated programs: these are just terms containing no open meta-variables.

Conclusions/Open problems ◮ dependent type theory as a nice place to study proof-term enriched presentations of logic ◮ machinery for type-checking/type synthesis/conversion testing modulo unknowns ◮ unification as a pervasive technology from traditional proof search ◮ correct-by-construction programming as well . . . which is type-directed, interactive, proof search ◮ many (?) more places during construction when unknowns allow progress without over-committing the programmer ◮ outstanding problem: high-level syntax for sufficient evidence to yield well-typed terms in the underlying theory