EPIGRAM 1: a perspective on functional programming with dependent types

Transcription

1 EPIGRAM 1: a perspective on functional programming with dependent types James McKinna, Radboud Universiteit Nijmegen james.mckinna@cs.ru.nl FP Dag, Utrecht, January 25, 2008 In samenwerking met: Conor McBride, Edwin Brady Dank ook aan: Russell, Johan, Anders, Rinus o.a.

2 Outline Some sloganeering on FP, problem solving, views... A little bit of dependent type theory (and mathematical induction) A key generalisation: elimination operators EPIGRAM by example Some design considerations for the kernel language Future prospects JHM: EPI@FPD Slide 1

3 A perspective on programming Verified/certified programming is... algorithmic problem-solving... which in turn is interactive human-guided (creative) machine-supported (routine) search for programs (and proofs) JHM: Slide 2

4 A perspective on functional programming Any computation is p :: String -> String (Unix!) organised as a composition of steps f :: A -> B for interesting choices of structured inputs A and structured outputs B typically A and B are (co-)inductive, so we decompose inputs from A by pattern matching and build outputs in B with (possibly smart) constructors steps can be partial, arising either from general recursion in f, or from A and/or B being too big plus some monadic, or nowadays applicative or arrow-like, plumbing of effects f :: A -> F B for interesting choices of F JHM: EPI@FPD Slide 3

5 A perspective on diagrammatic reasoning (Stenning, Klein, Oberlander; Edinburgh 1990s) Human beings use informal diagrammatic reasoning to: change the representation of the input data in such a way as to make the solution trivial to observe or conclude Contrast perhaps with more procedural or programmatic accounts of human problem solving. JHM: EPI@FPD Slide 4

6 Some computational instances Inverting an structure-erasing function yields a decision procedure, which splits an unstructured input into structured cases: bvb. (compile-time) a raw (untyped) λ-term is either the erasure of a well-typed term or, ill-typed, and you can compute where the type error(s) occurs (run-time) a well-typed λ-term is either a value or, a redex occurrence in an evaluation context A string is either the flattening of a successful parse tree... JHM: EPI@FPD Slide 5

7 A mathematical instance How to compute gcd and lcm of two integers m and n: either by Euclidean division, and then division or, using the fundamental theorem of arithmetic, then using zip min and zip max on the lists of prime factors of m and n The first emphasises computation (a little case analysis and a lot of iteration), the second structure (a data type of possibly sparse lists of prime factors) Fundamental tension: data vs. control JHM: EPI@FPD Slide 6

8 A simple, but important, example Suppose int i and int[] arr. When is lookup arr[i] safe? Suppose data Nat = Zero Succ Nat, length :: [a] -> Nat define lookup :: Nat -> [a] -> a Problem: cannot directly use precondition i<length l on the index to guarantee compile-time safety Idea: if i<length l then it is safe, so should be expressible as such, and otherwise is evidently too large i=k+(length l) JHM: EPI@FPD Slide 7

9 A perspective on pattern matching: views (Wadler,1985) Analyse f :: A -> B as g ; h :: A -> B where A is chosen for efficiency g :: h :: A -> A exposes evident structure on A, to support A -> B by pattern matching on this evident structure g is (should be) an isomorphism, so that no loss of information (but the inverse of g erases structure ) g can (should) be encapsulated via definition of the view A thereafter write functions h :: A -> B directly, as if A supported pattern matching (and g ensures that it does) JHM: EPI@FPD Slide 8

10 Problems You can t relate (at compile-time/via the type system) an input a :: with the intended output f a :: B. Possible solutions : A prove things by induction (bvb. Thompson) and hope/prove that non-termination isn t a problem you calculate; hand simulation plus a little induction (Burstall) you encapsulate as much as possible of the above in laws for map, fold, fusion, ezv. no solution for Wadler: need to trust that you have an isomorphism JHM: EPI@FPD Slide 9

11 Worse Case analysis, generalising boolean testing, loses information if you stick to Hindley-Milner (perhaps why GADTs have now become so fashionable): if b then t else f has type T, provide t and f both do, so testing b is insensitive at compile-time to which branch is taken... good for type inference and typechecking bad for trying to do safe lookup ezv. worse idiocies such as xs -> if (null xs) then (tail xs) else xs :: [a] -> [a] are not ruled out any value of a type will do for typechecking JHM: EPI@FPD Slide 10

12 A digression on mathematical induction fold A,B :: B -> (A -> B -> B) -> [A] -> B against listinduction A :: l : [A] P : pred [A] P(nil) ( a : A. l : [A].P(l) P(a : l)) Pl Take P λl.b then we have (modulo some argument rearrangement) listinduction A lp fold A,B l, while listinduction shows the patterns of case analysis on lists during a fold (plus the recursive calls!) JHM: EPI@FPD Slide 11

13 A crucial generalisation listinduction is not special in this regard... pattern matching is not special in this regard... primitive, indeed any well-founded recursion looks like this... general recursion itself (via the Y combinator), also looks like this So we can regard views of a type X as instances of this idea of generalised induction principle... and these principles just correspond to... doing induction over a strange data structure associated to X, namely the predicate which describes the patterns supported by the view (!) JHM: EPI@FPD Slide 12

14 Why all the fuss? With induction as first-class programming technique... we can formalise all the reasoning techniques which were previously external to the language you can witness the isomorphisms which views are intended to be based upon providing this evidence consists of... writing programs! however only induction comes for free; everything else must be defined And all functions end up total: explicit use of Y must be by passing it as a parameter (which you will then never be able to instantiate) JHM: EPI@FPD Slide 13

15 A good idea how to achieve this (ready-made) Curry, Howard, Martin-Löf, debruijn: take pred X X thus construct types P x :: out of values x :: X. We say P is a dependent family of types. Our interest focuses on inductively-defined such P. Indeed, could factor any such P through X TypeRep and TypeRep, for a type TypeRep of names for types in needing only one sort of dependent type family, and thus achieve, via TypeRep, generic programming within dependently-typed programming (McBride and Altenkirch, 2001) In any case, programming in dependent type theory is just FP, but more weird and more wonderful JHM: EPI@FPD Slide 14

16 A Kernel language design: EPIGRAM(1) Interactive, type-directed programming environment Inductive families of types, data... where Top-level let-bound total function definitions let... That s all folks! JHM: EPI@FPD Slide 15

17 Inductive families of types Include the usual (strictly positive) algebraic datatypes; Index information enforces stronger (A)DT invariants; Type-safe meta-programming for free; Control structures (can be) reified as data; JHM: Slide 16

18 Examples: simple algebraic datatypes Peano-Dedekind natural numbers data Nat : where 0 : Nat Also:... booleans, polymorphic lists... n : Nat Sn : Nat Definition of plus, cond, append as usual. JHM: EPI@FPD Slide 17

19 Including length information Bounded numbers data n : Nat Finn : where 0 n : FinSn i : Finn S n i : Fin (Sn) Vectors (lists with length) data A : n : Nat VecAn : where [] A : VecA0 v : A vs : VecAn v:: n vs : VecA(Sn) (NB. lengths are correlated with corresponding constructors) We get bounds-safe lookup : (i : Finn) (v : VecA n) A Inference-rule notation suppresses: notational noise: quantification, qualification, arrows implicit syntax (Pollack): arguments which can be inferred by usage JHM: EPI@FPD Slide 18

20 Bounded integers; branching on overflow Obvious function : Finn Nat Gives rise to a family over b,n : Nat expressing small integer property data where b,n : Nat Boundedb n : i : Finb Smalli : Boundedb i k : Nat Large k : Boundedb (b + k) Obvious function boundedb n : Boundedb n Now, case analysis on boundedb n gives the informative view of the unstructured pair of numbers b, n. JHM: EPI@FPD Slide 19

21 Classical Abstract Datatypes Balanced trees as an intermediate data structure for sorting: data c : Col h : Nat RBTc h : where a : A; l : RBTlc h ; r : RBTrc h Bnodea l r : RBTB(Sh) Bleaf : RBTB0 a : A ; l,r : RBTBh Rnodea l r : RBTRh Note: the invariant here is tightly specified; no wiggle room! Slogan: smart constructors are just constructors (for smarter types) JHM: EPI@FPD Slide 20

22 Control is data Continuation-passing style emphasises this point; Can redo Hutton-Wright Calculating an exceptional Interpreter (what about termination?); Classical ADT operations: break invariant; update ; repair programming pattern needs some help: zippers (RBTs again) McCarthy s idea of recursion-induction rehabilitated: computation traces are first-class data (there s much more to say about this topic) JHM: EPI@FPD Slide 21

23 Elimination with a motive and its generalisation Programming with (sub-) families can be (used to be) painful; Raw induction/elimination rules are too clumsy; Need for equational constraints (Clark completion); Type shape of elimination is what matters... Non-standard recursion or case analysis is OK... provided it is supported by evidence JHM: EPI@FPD Slide 22

24 Prospectus Now what? EPIGRAM(2): a new type theory and implementation What about computational effects? What about applications? Meanwhile: Agda 2 (Norell, Chalmers); Sozeau s language in Coq JHM: EPI@FPD Slide 23

25 EPIGRAM(2) See Conor s update in the recent HC&AR: key driver: a new type theory based on observational equality; complete overhaul of the implementation of inductive and coinductive families, via a universe; more challenging implementation techniques and issues: how to build a modular infrastructure for bi-directional typechcking, feature-by-feature; JHM: EPI@FPD Slide 24

26 What about infinite or interactive computation? Hancock/Setzer/Hyvernat: use Petersson/Synek trees Uustalu/Capretta/Altenkirch/McBride/... : finally sort out coinduction/corecursion properly, with nice syntax? Transaction models: memory, TCP/IP, http, ITasks? JHM: EPI@FPD Slide 25