Implementing an evaluator for mini-ML in ATS: a case of ...hwxi/academic/talks/WRS05slides.pdf ·...

Implementing an evaluator for mini-ML in ATS:a case of programming with theorem proving

Hongwei Xi

Boston University

Work partly funded by NSF grant CCR-0229480

Implementing an evaluator for mini-ML in ATS: a case of programming with theorem proving – p.1/35

Programming with theorem proving

What is it?

Where do we need it?

How can we support it?

This is fundamentally different from the paradigm ofextracting programs from proofs.

There are many design issues. Here is an analogy:

E = mc2 =⇒ a nuclear power plant


Applied Type System (ATS)

ATS is a recently developed framework to facilitate thedesign and formalization of (advanced) type systems insupport of practical programming.

The name applied type system refers to a type systemformed in ATS, which consists of two components:

static component (statics), where types are formedand reasoned about.dynamic component (dynamics), where programsare constructed and evaluated.

The key salient feature of ATS: statics is completelyseparate from dynamics. In particular, types cannotdepend on programs.


Examples of applied type systems:

The simply-typed λ-calculus

The second-order polymorphic λ-calculus (System F )

The higher-order polymorphic λ-calculus (System Fω)

Dependent ML (DML)

The second-order polymorphic λ-calculus with guardedrecursive types (impredicative formulation)


Non-Examples of applied type systems:

The dependent λ-calculus (λP )

The calculus of constructions (λC)


Syntax for statics

The statics is a simply typed language and a type in thestatics is referred to as a sort. We write b for a base sortand assume the existence of two special base sorts bool

and type.

sorts σ ::= b | σ1 → σ2

c-sorts σc ::= (σ1, . . . .σn) ⇒ σ

sta. terms s ::= a | sc(s1, . . . , sn) | λa : σ.s | s1(s2)

sta. var. ctx. Σ ::= ∅ | Σ, a : σ

Let us use B and T for static terms of sorts bool andtype, respectively.


Some static constants

1 : () ⇒ type

> : () ⇒ bool

⊥ : () ⇒ bool

→ : (type, type) ⇒ type

⊃ : (bool , type) ⇒ type

∧ : (bool , type) ⇒ type

≤tp : (type, type) ⇒ bool (impredicative formulation)

Also, for each sort σ, we assume that the two static construc-

tors ∀σ and ∃σ are assigned the sc-sort (σ → type) ⇒ type.


Some (unfamiliar) forms of types

Guarded type: B ⊃ T

Asserting type: B ∧ T

Here is an example involving both guarded and assertingtypes:

∀a : int .a ≥ 0 ⊃ (int(a) → ∃a′ : int .(a′ < 0) ∧ int(a′))

where int(I) is a singleton type for the integer equal to I.

This type can be assigned to a function from nonnegative

integers to negative integers.


Constraint relation

A constraint relation is of the following form:

Σ; ~B |= B

where ~B stands for a (possibly empty) sequence of staticboolean terms (often referred to as assumptions).

Here is an interesting question:

Is deduction modulo a special case where ~B is empty?


Syntax for dynamics

dyn. terms d ::= x | dc(d1, . . . , dn) |

lam x.d | app(d1, d2) |

⊃+ (v) | ⊃− (d) |

∀+(v) | ∀−(d) |

∧(d) | let ∧(x) = d1 in d2 |

∃(d) | let ∃(x) = d1 in d2

values v ::= x | dcc (v1, . . . , vn) | lam x.d |

⊃+ (v) | ∀+(v) | ∧(v) | ∃(v)

dyn. var. ctx. ∆ ::= ∅ | ∆, x : s


Typing judgment

A typing judgment is of the following form:

Σ; ~B; ∆ ` d : T


ATS

ATS is a programming language with a type system rootedin the framework ATS. In ATS, a variety of programmingparadigms are supported in a typeful manner, including:

Functional programming (available)

Object-oriented programming (available)

Imperative programming with pointers (available)

Modular programming (available)

Assembly programming (under development)

Here is the homepage of ATS:http://www.cs.bu.edu/˜hwxi/ATS/ATS.html


A datatype declaration in ATS (1)

datatype list (type, int) =| {a:type} nil (a, 0)| {a:type, n:int | n >= 0}

cons (a, n+1) of (a, list (a, n))

The concrete syntax means the following:

nil : ∀a : type. list(a, 0)

cons : ∀a : type.∀n : int .

n ≥ 0 ⊃ ((a, list(a, n)) ⇒ list(a, n + 1))


A datatype declaration in ATS (2)

datatype list (type, int) =| {a:type} nil (a, 0)| {a:type, n:nat}

cons (a, n+1) of (a, list (a, n))


nil : ∀a : type. list(a, 0)

cons : ∀a : type.∀n : nat . (a, list(a, n)) ⇒ list(a, n + 1)


A function declaration in ATS

fun append {a:type, m:nat, n:nat}(xs: list (a, m), ys: list (a, n)): list (a, m+n) =case xs of| nil () => ys| cons (x, xs) =>

cons (x, append (xs, ys))

The concrete syntax means that the function append isassigned the following type:

∀a : type.∀m : nat .∀n : nat .

(list(a,m), list(a, n)) → list(a,m + n)


Another function declaration in ATS

fun concat {a:type, m:nat, n:nat}(xss: list (list (a, n), m)): list (a, m*n) =case xss of| nil () => nil| cons (xs, xss) =>

append (xs, concat xss)

Unfortunately, this code currently cannot pass type-checking

in ATS because non-linear constraints on integers are in-

volved.


A dataprop declaration in ATS

dataprop MUL (int, int, int) =| {n:int} MULbas (0, n, 0)| {m:nat, n:int, p:int}

MULind (m+1, n, p+n) of MUL (m, n, p)| {m:pos, n:int, p:int}

MULneg (˜m, n, ˜p) of MUL (m, n, p)


0 ∗ n = 0

(m + 1) ∗ n = m ∗ n + n

(−m) ∗ n = −(m ∗ n)


A proof function declaration in ATS

prfun lemma {m:nat, n:nat, p:int} .<m>.(pf: MUL (m, n, p)): [p >= 0] prunit =

case* pf of| MULbas () => ’()| MULind pf’ =>

let prval _ = lemma pf’ in ’() endThe proof function proves:

∀m : nat .∀n : int .∀p : int .MUL(m,n, p) → (p ≥ 0) ∧ 1

We need to verify that lemma is a total function:

〈m〉 is a termination metric.

case? requires pattern matching to be exhaustive.


An example of programming with theorem proving

fun concat {a:type, m:nat, n:nat}(xss: list (list (a, n), m)): [p:nat] ’(MUL (m, n, p) | list (a, p)) =case xss of| nil () => ’(MULbas | nil)| cons (xs, xss) =>

let val ’(pf | res) = concat xss in’(MULind pf | append (xs, res))

end

Remark Proofs are completely erased before program

execution. In other words, there is no proof construction at

run-time.


Implementing mini-ML in ATS (1)

types T ::= nat | T1 ∗ T2 | T1 → T2

expressions e ::= x | z | s(e) | 〈e1, e2〉 | fst(e) | snd(e) |

lam x.e | app(e1, e2) | let x = e1 in e2 |

case e of (z ⇒ e1 | s(x) ⇒ e2) | fix x.e

values v ::= x | z | s(v) | 〈v1, v2〉 | lam x.e

Both the static semantics and the dynamic semantics of

mini-ML can be defined in a standard manner. Let us write

e → v to mean that the expression e evaluates to the value v

in mini-ML.


Implementing mini-ML in ATS (2)

We are to form a representation rep(e) for expressions e

in mini-ML.

We are to form a representation rep(v) for values v inmini-ML.

We are to implement a function evaluate such that if thethe functional call evaluate(rep(e)) returns, then itreturns rep(v) satisfying e → v.

We now use the pure call-by-value λ-calculus in the place of

mini-ML so as to make the presentation more accessible.


A first-order representation for pure λ-terms

datatype EXP =| One | Shi of EXP| Lam of EXP | App of (EXP, EXP)

The variables in λ-terms are represented as deBruijnindexes. For instance, λx.λy.y(x) can be represented as

Lam(Lam(App(One, Shi(One))))

It is straightforward to prove the adequacy of the represen-

tation.


A higher-order representation for pure λ-terms

datatype EXP =| Lam of (EXP -> EXP) | App of (EXP, EXP)

The variables in λ-terms are represented as meta-variables,that is, variables in the meta-language. For instance,λx.λy.y(x) can be represented as

Lam(lam x => Lam (lam y => App (y, x)))

In the dynamics of ATS, this is not an adequate representa-

tion. In particular, there are many values of type EXP that do

not correspond to any (pure) λ-terms.


Representing λ-terms in statics

datasort exp =| lm of (exp -> exp) | ap of (exp, exp)

datasort exps = none | more of (exps, exp)

Note that this is an adequate representation in the statics of

ATS.


Representing λ-terms in dynamics

datatype IN (exp, exps) =| {es:exps, e: exp} One (more (es, e), e)| {es:exps, e1:exp, e2:exp}

Shi (more (es, e2), e1) of EXP (es, e1)

datatype EXP (exps, exp) =| {es:exps, e:exp}

Var (es, e) of IN (e, es)| {es:exps, f:exp -> exp}

Lam (es, lm f) of{e: exp} EXP (more (es, e), f e)

| {es:exps, e1:exp, e2:exp}App (es, ap (e1, e2)) of(EXP (es, e1), EXP (es, e2))


Representing λ-terms in dynamics

Intuitively, we use a value of type EXP(e1 :: e2 :: . . . :: en, e) torepresent the expression e, where the (at most n) variablesin the value represents e1, . . . , en. For instance,

λx, λy.y(x) is represented as

Lam(Lam(App(Var INone, Var(INshi INone))))


Specifying call-by-value evaluation strategy

λx.e → λx.e(lam)

e1 → λx.e e2 → v1 e[x := v1] → v2

e1(e2) → v2

(app)

dataprop EVAL (exp, exp) =| {f: exp -> exp} EVALlam of (lm f, lm f)| {e1:exp, e2:exp, f: exp -> exp, v1:exp, v2:exp}

EVALapp (ap (e1, e2), v2) of(EVAL(e1,lm f), EVAL(e2,v1), EVAL(f v1,v2))


Specifying call-by-name evaluation strategy

λx.e → λx.e(lam)

e1 → λx.e e[x := e2] → e3

e1(e2) → e3

(app)

dataprop EVAL (exp, exp) =| {f: exp -> exp} EVALlam of (lm f, lm f)| {e1:exp, e2:exp, f: exp -> exp, e3:exp}

EVALapp (ap (e1, e2), e3) of(EVAL(e1, lm f), EVAL(f e2, e3))


Representing values

dataprop ISVAL (exp) =| {f:exp -> exp} ISVALlam (lm f)

datatype VAL (exp) =| {vs:exps, f:exp -> exp}

VALclo (lm f) of // closure(ENV vs, {v:exp} EXP(more(vs,v),f v))

and ENV (exps) = // environment| ENVnone (none)| {vs:exps,v:exp}

ENVmore (more (vs, v)) of(ISVAL v | ENV vs, VAL v)


Some proof functions

If v is a value, then v → v holds:prfun lemma1 {v:exp} .< >.

(pf: ISVAL v): EVAL (v, v) =case* pf of ISVALlam => EVALlam

If e → v holds, then v is a value:prfun lemma2 {e:exp, v:exp} .<?>.

(pf: EVAL (e, v): ISVAL v =case* pf of| EVALlam => ISVALlam| EVALapp (_, _, pf3) => lemma2 pf3


Implementing evaluation

fun eval {vs:exps, e:exp} (env: ENV (vs), e: EXP (vs, e))

: [v:exp] ’(EVAL (e, v) | VAL v) =

case e of

| Var i => evalVar (env, i)

| Lam body => ’(EVALlam | VALclo (env, body))

| EXPapp (e1, e2) =>

let

val ’(pf1 | VALclo (env’, body)) = eval (env, e1)

val ’(pf2 | arg) = eval (env, e2)

val ’(pf3 | v) =

eval (ENVmore (lemma2 pf2 | env’, arg), body)

in

’(EVALapp (pf1, pf2, pf3) | v)

end

and evalVar {vs:exps, v:exp} (env: ENV vs, i: IN (v, vs))

: ’(EVAL (v, v) | VAL v) = ...


Implementing evaluation (continued)

fun evaluate {e:exp} (e: EXP (none, e)): [v:exp] ’(EVAL (e, v) | VAL v) =eval (ENVnil, e)

So formally, the function evaluate is assigned the followingtype:

∀e : exp.EXP(none, e) → ∃v : exp.EVAL(e, v) ∗ VAL(v)


Related work

Theorem proving systems: NuPrl, Coq, ...

(Meta) Logical Frameworks: Twelf, ...

Functional Languages: Delphin, Omega, ...

Dependently Typed Functional Languages: Cayenne,Dependent ML, Epigram, ...

...


Conclusion and future directions

We have outlined a design to support programming withtheorem proving.

In addition, we have carried out this design in theprogramming language ATS.

The theme of programming with theorem proving ismuch broader than what is given in this talk. Forinstance, ATS is also equipped with a form of linearlogic (similar to but different from separation logic) toreason about memory properties, which forms the basisfor supporting safe use of pointers (e.g., pointerarithmetic).

We are currently also keen to formally supportreasoning on properties such as deadlocks and raceconditions.


The end of the talk

Thank you!


Implementing an evaluator for mini-ML in ATS: a case of ...hwxi/academic/talks/WRS05slides.pdf ·...

Documents

Transcript of Implementing an evaluator for mini-ML in ATS: a case of ...hwxi/academic/talks/WRS05slides.pdf ·...