A logical framework for incremental type-checking Matthias Puech 1 , 2 egis-Gianas 2 Yann R´ 1 Dept. of Computer Science, University of Bologna 2 University Paris 7, CNRS, and INRIA, PPS, team πr 2 May 2011 CEA LIST 1 / 28
A paradoxical situation Observation We have powerful tools to mechanize the metatheory of (proof) languages 2 / 28
A paradoxical situation Observation We have powerful tools to mechanize the metatheory of (proof) languages . . . And yet, Workflow of programming and formal mathematics is still largely inspired by legacy software development ( emacs , make , svn , diff s. . . ) 2 / 28
A paradoxical situation Observation We have powerful tools to mechanize the metatheory of (proof) languages . . . And yet, Workflow of programming and formal mathematics is still largely inspired by legacy software development ( emacs , make , svn , diff s. . . ) Isn’t it time to make these tools metatheory-aware? 2 / 28
Incrementality in programming & proof languages Q : Do you spend more time writing code or editing code? Today, we use: • separate compilation • dependency management • version control on the scripts • interactive toplevel with rollback ( Coq ) 3 / 28
Incrementality in programming & proof languages 4 / 28
Incrementality in programming & proof languages 4 / 28
Incrementality in programming & proof languages 4 / 28
Incrementality in programming & proof languages 4 / 28
Incrementality in programming & proof languages 4 / 28
Incrementality in programming & proof languages 4 / 28
Incrementality in programming & proof languages 4 / 28
Incrementality in programming & proof languages 4 / 28
In an ideal world. . . • Edition should be possible anywhere • The impact of changes visible “in real time” • No need for separate compilation, dependency management 5 / 28
In an ideal world. . . • Edition should be possible anywhere • The impact of changes visible “in real time” • No need for separate compilation, dependency management Types are good witnesses of this impact 5 / 28
In an ideal world. . . • Edition should be possible anywhere • The impact of changes visible “in real time” • No need for separate compilation, dependency management Types are good witnesses of this impact Applications • non-(linear | batch) user interaction • typed version control systems • type-directed programming • tactic languages 5 / 28
In this talk, we focus on. . . . . . building a procedure to type-check local changes • What data structure for storing type derivations? • What language for expressing changes? 6 / 28
Menu The big picture Incremental type-checking Why not memoization? Our approach Two-passes type-checking The data-oriented way A metalanguage of repository The LF logical framework Monadic LF Committing to MLF 7 / 28
Menu The big picture Incremental type-checking Why not memoization? Our approach Two-passes type-checking The data-oriented way A metalanguage of repository The LF logical framework Monadic LF Committing to MLF 8 / 28
The big picture version management script files parsing type-checking 9 / 28
The big picture version management script files parsing type-checking 9 / 28
The big picture script files version management parsing type-checking 9 / 28
The big picture script files parsing version management type-checking • AST representation 9 / 28
The big picture script files parsing version management type-checking • AST representation 9 / 28
The big picture user interaction parsing version management type-checking • AST representation 9 / 28
The big picture user interaction parsing type-checking version management • AST representation • Typing annotations 9 / 28
The big picture user interaction parsing incremental type-checking version management • AST representation • Typing annotations 9 / 28
A logical framework for incremental type-checking Yes, we’re speaking about (any) typed language. A type-checker val check : env → term → types → bool • builds and checks the derivation (on the stack) • conscientiously discards it 10 / 28
A logical framework for incremental type-checking Yes, we’re speaking about (any) typed language. A type-checker val check : env → term → types → bool • builds and checks the derivation (on the stack) • conscientiously discards it Ax A → B, B → C, A ⊢ B → C Ax Ax A → B, B → C, A ⊢ A → B A → B, B → C, A ⊢ A → e A → B, B → C, A ⊢ B → e A → B, B → C, A ⊢ C → i A → B, B → C ⊢ A → C → i A → B ⊢ ( B → C ) → A → C → i ⊢ ( A → B ) → ( B → C ) → A → C 10 / 28
A logical framework for incremental type-checking Yes, we’re speaking about (any) typed language. A type-checker val check : env → term → types → bool • builds and checks the derivation (on the stack) • conscientiously discards it true 10 / 28
A logical framework for incremental type-checking Goal Type-check a large derivation taking advantage of the knowledge from type-checking previous versions Idea Remember all derivations! 11 / 28
A logical framework for incremental type-checking Goal Type-check a large derivation taking advantage of the knowledge from type-checking previous versions Idea Remember all derivations! More precisely Given a well-typed R : repository and a δ : delta and apply : repository → delta → derivation , an incremental type-checker tc : repository → delta → bool decides if apply ( δ, R ) is well-typed in O ( | δ | ). (and not O ( | apply ( δ, R ) | )) 11 / 28
A logical framework for incremental type-checking Goal Type-check a large derivation taking advantage of the knowledge from type-checking previous versions Idea Remember all derivations! More precisely Given a well-typed R : repository and a δ : delta and apply : repository → delta → derivation , an incremental type-checker tc : repository → delta → repository option decides if apply ( δ, R ) is well-typed in O ( | δ | ). (and not O ( | apply ( δ, R ) | )) 11 / 28
A logical framework for incremental type-checking Goal Type-check a large derivation taking advantage of the knowledge from type-checking previous versions Idea Remember all derivations! from to 11 / 28
Memoization maybe? let rec check env t a = match t with | ... → ... false | ... → ... true and infer env t = match t with | ... → ... None | ... → ... Some a 12 / 28
Memoization maybe? let table = ref ([] : environ × term × types) in let rec check env t a = if List .mem (env,t,a) ! table then true else match t with | ... → ... false | ... → ... table := (env,t,a )::! table ; true and infer env t = try List .assoc (env,t) ! table with Not found → match t with | ... → ... None | ... → ... table := (env,t,a )::! table ; Some a 12 / 28
Memoization maybe? Syntactically + lightweight, efficient implementation 12 / 28
Memoization maybe? Syntactically + lightweight, efficient implementation + repository = table , delta = t 12 / 28
Memoization maybe? Syntactically + lightweight, efficient implementation + repository = table , delta = t – syntactic comparison (no quotient on judgements) What if I want e.g. weakening or permutation to be taken into account? 12 / 28
Memoization maybe? Syntactically + lightweight, efficient implementation + repository = table , delta = t – syntactic comparison (no quotient on judgements) What if I want e.g. weakening or permutation to be taken into account? Semantically – external to the type system (meta-cut) What does it mean logically? J ∈ Γ Γ 1 ⊢ J 1 wf ⇒ Γ 2 . . . Γ n − 1 [ J n − 1 ] ⊢ J n wf ⇒ Γ n Γ ⊢ J wf ⇒ Γ Γ 1 ⊢ J wf ⇒ Γ n [ J n ][ J ] 12 / 28
Memoization maybe? Syntactically + lightweight, efficient implementation + repository = table , delta = t – syntactic comparison (no quotient on judgements) What if I want e.g. weakening or permutation to be taken into account? Semantically – external to the type system (meta-cut) What does it mean logically? J ∈ Γ Γ 1 ⊢ J 1 wf ⇒ Γ 2 . . . Γ n − 1 [ J n − 1 ] ⊢ J n wf ⇒ Γ n Γ ⊢ J wf ⇒ Γ Γ 1 ⊢ J wf ⇒ Γ n [ J n ][ J ] – imperative (introduces a dissymmetry) 12 / 28
Memoization maybe? Syntactically + lightweight, efficient implementation + repository = table , delta = t – syntactic comparison (no quotient on judgements) What if I want e.g. weakening or permutation to be taken into account? Semantically – external to the type system (meta-cut) What does it mean logically? J ∈ Γ Γ 1 ⊢ J 1 wf ⇒ Γ 2 . . . Γ n − 1 [ J n − 1 ] ⊢ J n wf ⇒ Γ n Γ ⊢ J wf ⇒ Γ Γ 1 ⊢ J wf ⇒ Γ n [ J n ][ J ] – imperative (introduces a dissymmetry) Mixes two goals: derivation synthesis & object reuse 12 / 28
Menu The big picture Incremental type-checking Why not memoization? Our approach Two-passes type-checking The data-oriented way A metalanguage of repository The LF logical framework Monadic LF Committing to MLF 13 / 28
Recommend
More recommend
