A logical framework for incremental type-checking

(1)

A logical framework for incremental type-checking

Matthias Puech^1,2 Yann R´egis-Gianas²

1Dept. of Computer Science, University of Bologna

2University Paris 7, CNRS, and INRIA, PPS, teamπr²

?January 2011?

PPS – Groupe de travail théorie des types et réalisabilité

(2)

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, diffs. . . )

Isn’t it time to make these tools metatheory-aware?

(3)

A paradoxical situation

Observation

. . . And yet,

(4)

A paradoxical situation

Observation

. . . And yet,

(5)

Incrementality in programming & proof languages

Q ^:

Do you spend more timewritingcode oreditingcode?

Today, we use:

I separate compilation

I dependency management

I version control on the scripts

I interactive toplevel with rollback (Coq)

(6)

Incrementality in programming & proof languages

(7)

Incrementality in programming & proof languages

(8)

Incrementality in programming & proof languages

(9)

Incrementality in programming & proof languages

(10)

Incrementality in programming & proof languages

(11)

Incrementality in programming & proof languages

(12)

Incrementality in programming & proof languages

(13)

Incrementality in programming & proof languages

(14)

In an ideal world. . .

I Edition should be possible anywhere

I The impact of changes visible “in real time”

I No need for separate compilation, dependency management

Types are good witnesses of this impact

Applications

I non-linear user interaction

I tactic languages

I type-directed programming

I typed version control systems

(15)

In an ideal world. . .

Applications

I tactic languages

I typed version control systems

(16)

In an ideal world. . .

Applications

I tactic languages

(17)

A logical framework for incremental type-checking

Yes, we’re speaking about (any) typed language.

A type-checker

val check : env →term →types → bool

I builds and checks the derivation (on the stack)

I conscientiously discards it

→_i

→_e

A→B, B→C, A`B→C Ax A→B, B→C, A`A→BAx

A→B, B→C, A`AAx A→B, B→C, A`B →_e A→B, B→C, A`C

A→B, B→C`A→C A→B`(B→C)→A→C

`(A→B)→(B→C)→A→C

(20)

A logical framework for incremental type-checking

A type-checker

→_i

→_e

A→B, B→C, A`B→C Ax A→B, B→C, A`A→BAx

A→B, B→C, A`AAx A→B, B→C, A`B →_e A→B, B→C, A`C

A→B, B→C`A→C A→B`(B→C)→A→C

`(A→B)→(B→C)→A→C

(21)

A logical framework for incremental type-checking

A type-checker

true

(22)

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!

Q Do we really need faster type-checkers? A Yes, since we implemented these ad-hoc fixes.

(23)

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!

Q Do we really need faster type-checkers?

A Yes, since we implemented these ad-hoc fixes.

(24)

The big picture

version management script files

parsing type-checking

I AST representation

I Typing annotations

(25)

The big picture

version management

script files parsing

type-checking

(26)

The big picture

script files

version management

parsing type-checking

(27)

The big picture

version management type-checking

(28)

The big picture

(29)

The big picture

user interaction parsing

(30)

The big picture

type-checking

version management

(31)

The big picture

incremental type-checking version management

(32)

Memoization maybe?

let rec check env t a = matcht with

| ... → ... false

| ... → ... true and infer env t =

matcht with

| ... → ... None

| ... → ... Some a

+ lightweight

+ efficient implementation – imperative

What does it mean logically?

J∈Γ Γ`Jwf⇒Γ

Γ1`J1 wf⇒Γ2 . . . Γn−1[Jn−1]`Jnwf⇒Γn

Γ1`J wf⇒Γn[Jn][J]

– external to the logic (meta-cut) – introduces a dissymmetry

What if I wante.g. the weakening property to be taken into account?

– syntactic comparison

– still no trace of the derivation + gives good reasons to go on

(34)

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 matchtwith

| ... → ... false

| ... → ... table := (env, t ,a )::! table ; true and infer env t =

try List . assoc (env, t) ! table with Not found→ matchtwith

| ... → ... None

| ... → ... table := (env, t ,a )::! table ; Some a

+ lightweight

J∈Γ Γ`Jwf⇒Γ

(35)

Memoization maybe?

+ lightweight

J∈Γ Γ`Jwf⇒Γ

(36)

Memoization maybe?

+ lightweight

+ efficient implementation

– imperative

J∈Γ Γ`Jwf⇒Γ

(37)

Memoization maybe?

+ lightweight

J∈Γ Γ`Jwf⇒Γ

(38)

Memoization maybe?

+ lightweight

J∈Γ Γ`Jwf⇒Γ

(39)

Memoization maybe?

+ lightweight

J∈Γ Γ`Jwf⇒Γ

– external to the logic (meta-cut)

– introduces a dissymmetry

(40)

Memoization maybe?

+ lightweight

J∈Γ Γ`Jwf⇒Γ

(41)

Memoization maybe?

+ lightweight

J∈Γ Γ`Jwf⇒Γ

(42)

Memoization maybe?

+ lightweight

J∈Γ Γ`Jwf⇒Γ

(43)

Memoization maybe?

+ lightweight

J∈Γ Γ`Jwf⇒Γ

+ gives good reasons to go on

(44)

Memoization maybe?

+ lightweight

J∈Γ Γ`Jwf⇒Γ

– still no trace of the derivation

(45)

A popular storage model for repositories

/

/foo /bar

/foo/a /bar/b /bar/c

v1

(46)

A popular storage model for repositories

/

/foo /bar

/

/bar

/bar/c'

v1

/foo

/foo/a /bar/b

(47)

A popular storage model for repositories

/

/foo /bar

/

/bar

/bar/c'

v1

(48)

A popular storage model for repositories

/

/foo /bar

/

/bar

/bar/c'

v1

v2

(49)

A popular storage model for repositories

/

/foo /bar

/

/bar

99dcf1d 46f9c2 923ace3

c328e8f d54c809

6e4f99a

4244e8a

cf189a6

e33478f

/bar/c'

v1

v2

820e7ab

a85f0b77

(50)

A popular storage model for repositories

/

/foo /bar

/

/bar

c328e8f d54c809

6e4f99a

4244e8a

cf189a6

e33478f 99dcf1d → "Hello World"

d54c809 → 46f9c2, 923ace3 6ef99a → 99dcf1d 4244e8a → 6e4f99a, d54c809 cf189a6 → 46f9c2, c328e8f ...

/bar/c'

v1

v2

820e7ab

a85f0b77

(51)

A popular storage model for repositories

/

/foo /bar

/

/bar

c328e8f d54c809

6e4f99a

4244e8a

cf189a6

e33478f 99dcf1d → "Hello World"

d54c809 → 46f9c2, 923ace3 6ef99a → 99dcf1d 4244e8a → 6e4f99a, d54c809 cf189a6 → 46f9c2, c328e8f ...

/bar/c'

v1

v2

820e7ab

a85f0b77 a85f0b77

⊢

(52)

A popular storage model for repositories

The repositoryR is a pair (∆, x):

∆ :x7→(Commit (x×y) |Tree~x |Blob string) with the invariants:

I if (x,Commit (y, z))∈∆ then

I (y,Tree t)∈∆

I (z,Commit(t, v))∈∆

I if (x,Tree(~y))∈∆ then

for all y_i, either (y_i,Tree(~z)) or (y_i,Blob(s))∈∆

Let’s do the same with proofs

(53)

A popular storage model for repositories

The repositoryR is a pair (∆, x):

∆ :x7→(Commit (x×y) |Tree~x |Blob string) with the invariants:

I if (x,Commit (y, z))∈∆ then

I (y,Tree t)∈∆

I (z,Commit(t, v))∈∆

I if (x,Tree(~y))∈∆ then

for all y_i, either (y_i,Tree(~z)) or (y_i,Blob(s))∈∆

Let’s do the same with proofs

(54)

A typed repository of proofs

v1 - - : ⊢ C

λ- : ⊢(A∧B)→C -,- : ⊢ A∧B π₁ : A∧B⊢C π₂ : ⊢A π₃ : ⊢B

(55)

A typed repository of proofs

- - : ⊢ C v1

- - : ⊢ C λ- : ⊢(A∧B)→C

-,- : ⊢ A∧B -,- : ⊢ A∧B

π₁ : A∧B⊢C π₂ : ⊢A π₃ : ⊢B

π₃' : ⊢B

λ- : ⊢(A∧B)→C

π₁ : A∧B⊢C π₂ : ⊢A

(56)

A typed repository of proofs

- - : ⊢ C v1

- - : ⊢ C λ- : ⊢(A∧B)→C

-,- : ⊢ A∧B -,- : ⊢ A∧B

π₁ : A∧B⊢C π₂ : ⊢A π₃ : ⊢B

π₃' : ⊢B

(57)

A typed repository of proofs

- - : ⊢ C v1

v2 - - : ⊢ C

λ- : ⊢(A∧B)→C

-,- : ⊢ A∧B -,- : ⊢ A∧B

π₁ : A∧B⊢C π₂ : ⊢A π₃ : ⊢B

π₃' : ⊢B

(58)

A typed repository of proofs

- - : ⊢ C v1

v2 - - : ⊢ C

λ- : ⊢(A∧B)→C

-,- : ⊢ A∧B -,- : ⊢ A∧B

π₁ : A∧B⊢C π₂ : ⊢A π₃ : ⊢B

π₃' : ⊢B

x y z

t

v w

s r

q u p

(59)

A typed repository of proofs

x=. . . :A∧B`C y=. . . :`A z=. . . :`B

t=λaÂ∧B·x:À∧B→C u= (y, z) : À∧B

v=t u:`C

w=Commit(v, w1) :Version

(60)

A typed repository of proofs

x=. . . :A∧B`C y=. . . :`A z=. . . :`B

v=t u:`C

w=Commit(v, w1) :Version , w

(61)

A typed repository of proofs

x=. . . :A∧B`C y=. . . :`A z=. . . :`B

v=t u:`C

w=Commit(v, w1) :Version p=. . . :`B

q= (y, p) :`A∧B r=t q:`C

s=Commit(r, w) :Version

(62)

A typed repository of proofs

x=. . . :A∧B`C y=. . . :`A z=. . . :`B

v=t u:`C

w=Commit(v, w1) :Version p=. . . :`B

q= (y, p) :`A∧B r=t q:`C

s=Commit(r, w) :Version , s

(63)

A typed repository of proofs

...

val is : env→prop→type val conj : prop→prop→prop

val pair : is α β→isα γ →isα(conj β γ) val version : type

val commit : is nil C→version→version ...

let x = ... : is (cons (conj A B) nil ) Cin let y = ... : is nil Ain

let z = ... : is nil Bin

let t = lam (conj A B) x : is nil ( arr (conj A B) C)in let u = pair y z : is nil (conj A B)in

let v = app t u : is nil Cin let w = commit v w1 : versionin

w

(64)

A typed repository of proofs

...

val pair : is α β→isα γ →isα(conj β γ) val version : type

let p = ... : is nil B

let q = pair y p : is nil (conj A B)in let r = t q : is nil C

(65)

A typed repository of proofs

...

val pair : is α β→isα γ→isα(conj β γ) val version : type

let p = ... : is nil B

let q = pair y p : is nil (conj A B)in let r = t q : is nil C

(66)

A logical framework for incremental type-checking

LF [Harper et al. 1992] provides a way to represent and validate syntax, rules and proofs by means of a typedλ-calculus. But we need a little bit more:

. . .

letu = pair y z : is nil (conj A B)in letv = app t u : is nil Cin . . .

1. definitions / explicit substitutions 2. type annotations on application spines 3. fully applied constants / η-long NF

4. Naming of all application spines / A-normal form

(= construction of syntax/proofs)

(67)

A logical framework for incremental type-checking

. . .

1. definitions / explicit substitutions

2. type annotations on application spines 3. fully applied constants / η-long NF

(68)

A logical framework for incremental type-checking

. . .

1. definitions / explicit substitutions 2. type annotations on application spines

3. fully applied constants / η-long NF

(69)

A logical framework for incremental type-checking

. . .

letu =pair y z: is nil (conj A B)in letv = app t u : is nil Cin . . .

(70)

A logical framework for incremental type-checking

. . .

letu= pair y z : is nil (conj A B)in letv= app t u : is nil Cin . . .

(71)

Positionality

R=

w

I Expose the headof the term

(λx.λy.T ) U V

I Abstract from the positions of the binders

(from inside and from outside)

(72)

Positionality

R=

w

(λx.λy.T ) U V

(73)

Positionality

R=

w

(λx.λy.T ) U V

(74)

Positionality

R=

w

(λx.λy.T ) U V

(75)

Presentation (of the ongoing formalization)

I alternative syntax for LF

I a datastructure of LF derivations

I the repository storage model

Motto: Take control of the environment

λ_LF

LJ-style annotation

−−−−−−−−−−−→ XLF

heads exposed forget positions

−−−−−−−−−−−→ NLF

(77)

From LF to XLF

K ::= Πx^A·K | ∗ A ::= Πx^A·A |A t|a

t ::= λx^A·t |letx=t in t|t t |x |c Γ ::= · |Γ [x:A] |Γ [x=t]

Σ ::= · |Σ [c:A] |Σ [a:K]

I start from standardλ_LF with definitions

I sequent calculus-like applications (¯λ)

I type annotations on application spines

I named arguments

(78)

From LF to XLF

K ::= Πx^A·K | ∗

A ::= Πx^A·A |A[l]|a[l]

t ::= λx^A·t |letx=t in t|t[l]|x[l]|c[l]

l ::= · |t;l

Γ ::= · |Γ [x:A] |Γ [x=t]

Σ ::= · |Σ [c:A] |Σ [a:K]

I named arguments

(79)

From LF to XLF

K ::= Πx^A·K | ∗

A ::= Πx^A·A |A[l] :K |a[l] :K

t ::= λx^A·t |letx=t in t|t[l] :A |x[l] :A |c[l] :A l ::= · |t;l

Γ ::= · |Γ [x:A] |Γ [x=t]

Σ ::= · |Σ [c:A] |Σ [a:K]

I named arguments

(80)

From LF to XLF

K ::= Πx^A·K | ∗

A ::= Πx^A·A |A[l] :K |a[l] :K

Γ ::= · |Γ [x:A] |Γ [x=t]

Σ ::= · |Σ [c:A] |Σ [a:K]

I named arguments

(81)

From LF to XLF

K ::= Πx^A·K | ∗

A ::= Πx^A·A |A[l] :K |a[l] :K

Γ ::= · |Γ [x:A] |Γ [x=t]

Σ ::= · |Σ [c:A] |Σ [a:K]

I named arguments

(82)

From LF to XLF

K ::= Πx^A·K | ∗

A ::= Πx^A·A |A[l] :K |a[l] :K

t ::= λx^A·t |letx=t in t|t[l] :A |x[l] :A |c[l] :A l ::= · |x=t;l

Γ ::= · |Γ [x:A] |Γ [x=t]

Σ ::= · |Σ [c:A] |Σ [a:K]

I named arguments

(83)

From LF to XLF

K ::= Πx^A·K | ∗

A ::= Πx^A·A |A[l] :K |a[l] :K

t ::= λx^A·t |letx=t in t|t[l] :A |x[l] :A |c[l] :A l ::= · |x=t;l

Γ ::= · |Γ [x:A] |Γ [x=t]

Σ ::= · |Σ [c:A] |Σ [a:K]

I named arguments

(84)

XLF: Properties

I LJ-style application

I type annotation on application spines

I named arguments (labels) Lemma (Conservativity)

I Γ`_LF K kind iff |Γ| `_XLF|K| kind

I Γ`_LF A type iff |Γ| `_XLF|A|type

I Γ`_LF t:A iff |Γ| `_XLF|t|:|A|

(85)

From XLF to NLF

K ::= Πx^A·K | ∗

A ::= Πx^A·A |A[l] :K |a[l] :K

t ::= λx^A·t |letx=t in t|t[l] :A |x[l] :A |c[l] :A l ::= · | x=t;l

Γ ::= · |Γ [x:A] |Γ [x=t]

Σ ::= · |Σ [c:A] |Σ [a:K]

I start from XLF

I isolate heads (non-binders)

I enforceη-long forms by annotating with heads

I factorize binders and environments

I abstract over environment datastructure (maps)

(86)

From XLF to NLF

K ::= Πx^A·K |hK

hK ::= ∗

A ::= Πx^A·A |A[l] :K |a[l] :K

t ::= λx^A·t|let x=tin t |t[l] :A|x[l] :A|c[l] :A l ::= · |x=t;l

Γ ::= · |Γ [x:A] |Γ [x=t]

Σ ::= · |Σ [c:A] |Σ [a:K]

I start from XLF

(87)

From XLF to NLF

K ::= Πx^A·K |hK

hK ::= ∗

A ::= Πx^A·A |hA

hA ::= A[l] :K |a[l] :K

t ::= λx^A·t|let x=tin t |t[l] :A|x[l] :A|c[l] :A l ::= · |x=t;l

Γ ::= · |Γ [x:A] |Γ [x=t]

Σ ::= · |Σ [c:A] |Σ [a:K]

I start from XLF

(88)

From XLF to NLF

K ::= Πx^A·K |hK

hK ::= ∗

A ::= Πx^A·A |hA

hA ::= A[l] :K |a[l] :K

t ::= λx^A·t|let x=tin t |ht

h_t ::= t[l] :A |x[l] :A |c[l] :A l ::= · |x=t;l

Γ ::= · |Γ [x:A] |Γ [x=t]

Σ ::= · |Σ [c:A] |Σ [a:K]

I start from XLF

(89)

From XLF to NLF

K ::= Πx^A·K |hK

hK ::= ∗

A ::= Πx^A·A |hA

hA ::= A[l] :hK |a[l] :hK

h_t ::= t[l] :A |x[l] :A |c[l] :A l ::= · |x=t;l

Γ ::= · |Γ [x:A] |Γ [x=t]

Σ ::= · |Σ [c:A] |Σ [a:K]

I start from XLF

enforceη-long forms by annotating with heads

(90)

From XLF to NLF

K ::= Πx^A·K |hK

hK ::= ∗

A ::= Πx^A·A |hA

h_t ::= t[l] :h_A |x[l] :h_A|c[l] :h_A l ::= · |x=t;l

Γ ::= · |Γ [x:A] |Γ [x=t]

Σ ::= · |Σ [c:A] |Σ [a:K]

I start from XLF

(91)

From XLF to NLF

K ::= Πx^A·K |hK

hK ::= ∗

A ::= Πx^A·A |hA

Γ ::= · |Γ [x:A] |Γ [x=t]

Σ ::= · |Σ [c:A] |Σ [a:K]

I start from XLF

(92)

From XLF to NLF

K ::= Πx^A·K |hK

hK ::= ∗

A ::= Πx^A·A |hA

t ::= Γ`h_t

Γ ::= · |Γ [x:A] |Γ [x=t]

Σ ::= · |Σ [c:A] |Σ [a:K]

I start from XLF

(93)

From XLF to NLF

K ::= Πx^A·K |hK

hK ::= ∗ A ::= Γ`hA

h_A ::= A[l] :h_K |a[l] :h_K t ::= Γ`h_t

ht ::= t[l] :h_A |x[l] :h_A|c[l] :h_A l ::= · |x=t;l

Γ ::= · |Γ [x:A] |Γ [x=t]

Σ ::= · |Σ [c:A] |Σ [a:K]

I start from XLF

(94)

From XLF to NLF

K ::= Γ`h_k hK ::= ∗

A ::= Γ`hA

h_A ::= A[l] :h_K |a[l] :h_K t ::= Γ`h_t

ht ::= t[l] :h_A |x[l] :h_A|c[l] :h_A l ::= · |x=t;l

Γ ::= · |Γ [x:A] |Γ [x=t]

Σ ::= · |Σ [c:A] |Σ [a:K]

I start from XLF

(95)

From XLF to NLF

K ::= Γ`h_k hK ::= ∗

A ::= Γ`hA

h_A ::= A[l] :h_K |a[l] :h_K t ::= Γ`h_t

ht ::= t[l] :h_A |x[l] :h_A|c[l] :h_A l ::= Γ

Γ ::= · |Γ [x:A] |Γ [x=t]

Σ ::= · |Σ [c:A] |Σ [a:K]

I start from XLF

(96)

From XLF to NLF

K ::= Γ`h_k hK ::= ∗

A ::= Γ`hA

h_A ::= A[l] :h_K |a[l] :h_K t ::= Γ`h_t

ht ::= t[l] :h_A |x[l] :h_A|c[l] :h_A l ::= Γ

Γ : x7→([x:A] | [x=t]) Σ ::= · |Σ [c:A] |Σ [a:K]

I start from XLF

(97)

NLF

Syntax

K ::= Γ kind A ::= Γ`hA type h_A ::= aΓ

t ::= Γ`h_t:h_A ht ::= tΓ |x Γ|c Γ

Γ : x7→([x:a] | [x=t])

Judgements

I Γ kind

I Γ`hAtype

(98)

NLF

Syntax

Γ : x7→([x:a] | [x=t])

Judgements

I K

I A

(99)

NLF

Syntax

Γ : x7→([x:a] | [x=t])

Judgements

I K wf

I A wf

(100)

NLF

Notations

I “h_A” for “`h_A”

I “hA” for “∅ `hA type”

I “a” for “a∅”

Example

λf^A→B·λx^A·f x: (A→B)→A→B ≡ [f : [a:A]`B type] [x:A]`f [a=x] :B

(101)

Some more examples

A: ∅ kind

≡ ∗

vec: [len:N]kind

≡N→ ∗

nil : `vec [len= `0 :N]type

≡vec0 :∗

cons: [l:N] [hd:A] [tl: `vec [len= ` l:N]type]` vec [len= `s [n= `l:N] :N]type

≡Πl^N·A→Πtl^{vec l}·vec(s l:N) :∗

f ill : [n:N]`vec [len= `n:N]type

≡Πn^N·(vec n:∗)

empty : [e:vec [len= 0]]kind

≡vec0→ ∗

(102)

Environments

. . . double as labeleddirected acyclic graphsof dependencies:

Definition (environment)

Γ = (V, E) directed acyclic where:

I V ⊆ X ×(t]A) and

I (x, y)∈E (x depends ony) if y∈FV(Γ(x)) Definition (lookup)

Γ(x) :A if (x, A)∈E Γ(x) =t if (x, t)∈E Definition (bind)

Γ [x:A] = (V ∪(x, A), E∪ {(x, y) |y∈FV(A)}) Γ [x=t] = (V ∪(x, A), E∪ {(x, y) |y∈FV(t)})

(103)

Environments

. . . double as labeleddirected acyclic graphsof dependencies:

Definition (decls, defs)

decls(Γ) = [x1, . . . , xn] s.t. Γ(xi) :Ai topologically sortedwrt. Γ defs(Γ) = [x1, . . . , xn] s.t. Γ(xi) =ti topologically sorted wrt. Γ Definition (merge)

Γ·∆ = Γ∪∆ s.t.

I if Γ(x) :A and Γ(x) =tthen Γ·∆(x) =t

I undefined otherwise

A logical framework for incremental type-checking

A logical framework for incremental type-checking

A paradoxical situation

A paradoxical situation

A paradoxical situation

Incrementality in programming & proof languages

Q :

Incrementality in programming & proof languages

Incrementality in programming & proof languages

Incrementality in programming & proof languages

Incrementality in programming & proof languages

Incrementality in programming & proof languages

Incrementality in programming & proof languages

Incrementality in programming & proof languages

Incrementality in programming & proof languages

In an ideal world. . .

In an ideal world. . .

In an ideal world. . .

Menu

Menu

A logical framework for incremental type-checking

A logical framework for incremental type-checking

A logical framework for incremental type-checking

A logical framework for incremental type-checking

A logical framework for incremental type-checking

The big picture

The big picture

The big picture

The big picture

The big picture

The big picture

The big picture

The big picture

Menu

Memoization maybe?

Memoization maybe?

Memoization maybe?

Memoization maybe?

Memoization maybe?

Memoization maybe?

Memoization maybe?

Memoization maybe?

Memoization maybe?

Memoization maybe?

Memoization maybe?

Memoization maybe?

A popular storage model for repositories

A popular storage model for repositories

A popular storage model for repositories

A popular storage model for repositories

A popular storage model for repositories

A popular storage model for repositories

A popular storage model for repositories

A popular storage model for repositories

Let’s do the same with proofs

A popular storage model for repositories

Let’s do the same with proofs

A typed repository of proofs

A typed repository of proofs

A typed repository of proofs

A typed repository of proofs

A typed repository of proofs

A typed repository of proofs

A typed repository of proofs

A typed repository of proofs

A typed repository of proofs

A typed repository of proofs

A typed repository of proofs

A typed repository of proofs

A logical framework for incremental type-checking

A logical framework for incremental type-checking

A logical framework for incremental type-checking

A logical framework for incremental type-checking

A logical framework for incremental type-checking

Positionality

(λx.λy.T ) U V

Positionality

(λx.λy.T ) U V

Positionality

(λx.λy.T ) U V

Q ^: