The PML Language · The PML Language: Realizability at the Service of Program Proofs Rodolphe Lepigre Realizability workshop { 08/03/2018 { Marseille. ... give the syntax oz programs

The PML Language:Realizability at the Service of Program Proofs

Rodolphe LepigreRealizability workshop { 08/03/2018 { Marseille

Using OCaml as a Proof System: A Silly Idea?

(* Empty type (logical absurdity). *)

type empty = { empty : 'a. 'a }

(* Logical negation. *)

type 'a neg = 'a � empty

(* The law of the excluded middle. *)

type 'a excluded_middle =

| True of 'a

| False of 'a neg

Rodolphe Lepigre 1 / 34

Using OCaml as a Proof System: A Silly Idea?

(* Empty type (logical absurdity). *)

type empty = { empty : 'a. 'a }

(* Logical negation. *)

type 'a neg = 'a � empty

(* The law of the excluded middle. *)

type 'a excluded_middle =

| True of 'a

| False of 'a neg

(* The law of the excluded middle implies double negation elimination. *)

let proof : 'a excluded_middle � 'a neg neg � 'a = fun em h �

match em with

| True a � a

| False not_a � (h not_a).empty


Toward a Programming Language, with Program Proving Features

An ML-like programming language with:

records, variants (constructors), ,

polymorphism, ,

a call-by-value evaluation strategy,

efzects (control operators),

a Curry-style syntax (light) and .


subtyping

general recursion

inductive types




polymorphism, ,




For proving program, the type system is enriched with:

programs as individuals (higher-order layer),

an equality type t� u (observational equivalence),

a dependent zunction type (typed quanti{cation).


Termination checking is required zor proozs.

subtyping

general recursion

inductive types




polymorphism, ,




For proving program, the type system is enriched with:

programs as individuals (higher-order layer),

an equality type t� u (observational equivalence),

a dependent zunction type (typed quanti{cation).


Termination checking is required zor proozs.

subtyping

general recursion

inductive types

Example of Program and Proof

type rec nat = [Zero ; S of nat]

val rec add : nat � nat � nat =

fun n m { case n { Zero � m | S[k] � S[add k m] } }






val add_Zero_m : �m�nat, add Zero m � m =

fun m { {} }






val add_Zero_m : �m�nat, add Zero m � m =

fun m { {} }

val rec add_n_Zero : �n�nat, add n Zero � n =

fun n {

case n {

Zero � {}

S[p] � add_n_Zero p

}

}


Part III Specificities of the Type System

Part III Formalisation of the System and Semantics

Part III Semantical Value Restriction


Part I

Specificities of the Type System


Properties as Program Equivalences

Examples oz (equational) program properties:

add (add m n) k � add m (add n k) (associativity oz add)

rev (rev l) � l (rev is an involution)

map g (map f l) � map (fun x {g (f x)}) l (map and composition)

sort (sort l) � sort l (sort is idempotent)


Properties as Program Equivalences

Examples oz (equational) program properties:

add (add m n) k � add m (add n k) (associativity oz add)

rev (rev l) � l (rev is an involution)

map g (map f l) � map (fun x {g (f x)}) l (map and composition)

sort (sort l) � sort l (sort is idempotent)

Speci{cation oz a sorting zunction using predicates:

is_increasing (sort l) � true (sort produces a sorted list)

is_perm (sort l) l � true (sort yields a permutation)


Equality Types and Equivalence

We consider a new type zormer t� u (where t and u are untyped terms).




It is interpreted as:

� (the unit type) iz t and u are |equivalent},

� (the empty type) otherwise.








dec. proc. says |yes}

� ; t :� u � u1 2

� ; t : u � u1 2








� ; t :� u � u1 2

� ; t : u � u1 2

�, x :� ; , u � u t : C1 2

�, x : u � u ; t : C1 2






Remark: equivalence is undecidable.



� ; t :� u � u1 2

� ; t : u � u1 2

�, x :� ; , u � u t : C1 2

�, x : u � u ; t : C1 2






Remark: equivalence is undecidable.

Remark: decision oz equivalence only needs to be correct.



� ; t :� u � u1 2

� ; t : u � u1 2

�, x :� ; , u � u t : C1 2

�, x : u � u ; t : C1 2

First-Order Quantification is not Enough







val add_Zero_m : �m, add Zero m � m = {- ??? -}





val add_Zero_m : �m, add Zero m � m = {}

// Immediate by definition







val add_n_Zero : �n, add n Zero � n = {- ??? -}








// Nothing we can do








// Nothing we can do

We need a zorm oz typed quanti{cation!


Dependent Functions for Typed Quantification


fun n {

case n {

Zero � {}


}

}




fun n {

case n {

Zero � {}


}

}

Remark: we may inspect the elements oz the domain.




fun n {

case n {

Zero � {}


}

}



�, x : A ; t : B

� ; �x.t : �x�A.B



fun n {

case n {

Zero � {}


}

}



�, x : A ; t : B

� ; �x.t : �x�A.B

� ; t : �x�A.B � ; v : A

� ; t v : B[x� v]

Structuring Proofs with Dummy Programs

val rec add_n_Sm : �n m�nat, add n S[m] � S[add n m] =

fun n m {

case n {

Zero � {}

S[k] � add_n_Sm k m

}

}

val rec add_comm : �n m�nat, add n m � add m n =

fun n m {

case n {

Zero � add_n_Zero m

S[k] � add_n_Sm m k; add_comm k m

}

}


Part II

Formalisation of the System and Semantics


Realizability Model

We build a model to prove that the language has the expected properties.


Realizability Model


To construct the model, we need to:

1) give the syntax oz programs and types,

2) de{ne the interpretation oz types as sets oz terms (uses reduction),

3) de{ne adequate typing rules,

4) deduce termination, type safety and consistency.


Realizability Model


To construct the model, we need to:

1) give the syntax oz programs and types,

2) de{ne the interpretation oz types as sets oz terms (uses reduction),

3) de{ne adequate typing rules,

4) deduce termination, type safety and consistency.

Advantage: it is modular (contrary to type preservation).


Call-by-Value Abstract Machine


�� seulaV w,v =:: ]v[Ck|})vi=l i(I�i

{|t.x�|x

��smreT u,t =:: t]�[|t.��|])t i�]x i[Ci(I�i

|v[|lk.v|u t|v

��skcatS �,� =:: )txetnocnoitaulave(�]t[|�.v|�|�

sessecorP q,p =:: ��t

Call-by-value Reduction Relation


��u t � �]t[�u

�]t[�v � �.v�t

�.v�t.x� � ��]v�x[t

��lk.})vi=l i(I�i

{ � ��vk �I�k�

��])t i�]x i[Ci(I�i

|]v[Ck[ � ��]v�xk[tk �I�k�

��t.�� ]��[t

��t]�[ � ��t

Successful Computation and Observational Equivalence

The abstract machine may either:

successzully compute a result (it converges),

zail with a runtime error or never terminate (it diverges).






�Dewnition: we write t � � � ifz t � � � v � � zor some value v (t � � � otherwise).







(�x.x) {} � �� (�x.x x) (�x.x x) � �� (�x.t).l � ��1







(�x.x) {} � �� (�x.x x) (�x.x x) � �� (�x.t).l � ��1

Dewnition: two terms are equivalent iz they converge in the same contexts.







(�x.x) {} � �� (�x.x x) (�x.x x) � �� (�x.t).l � ��1


� � � �� = t , u | � � , t � � � � u � � � X�v







(�x.x) {} � �� (�x.x x) (�x.x x) � �� (�x.t).l � ��1


� � � �� = t , u | � � , �� , t� � � � � u� � � � X�v


Types as Sets of Canonical Values

� � � �Dewnition: a type A is interpreted as a set oz values A closed under � .


Types as Sets of Canonical Values

� � � �Dewnition: a type A is interpreted as a set oz values A closed under � .


�}A2:l2;A1:l1{� = � X�v�A2

��v2 �A1��v1|}v2=l2;v1=l1{�

�]A2:C2|A1:C1[� = � X�v�Ai

��v 2,1�i|]v[Ci�

�A.X�� =�]��X[A��

epyt�

�A.X�� =�]��X[A��

epyt�

�A.x�� = �]t�a[A��eulavv

�A.x�� = �]t�a[A��eulavv

Membership Types and Dependency

We consider a new membership type t�A (with t a term, A a type).

� � � � It is interpreted as t�A = v � A | t � v ,

and allows the introduction oz dependency.


Membership Types and Dependency

We consider a new membership type t�A (with t a term, A a type).

� � � � It is interpreted as t�A = v � A | t � v ,

and allows the introduction oz dependency.

The dependent zunction type �x�A.B

is de{ned as �x.(x�A � B),

this is a zorm oz relativised quantizcation scheme.


Semantic Restriction Type and Equalities

We also consider a new restriction type A � P:

it is build using a type A and a |semantic predicate} P,

� � � � � �A � P is equal to A iz P is satis{ed and to � otherwise.

We can use predicates like t � u , ¬P or P Q.


Semantic Restriction Type and Equalities

We also consider a new restriction type A � P:

it is build using a type A and a |semantic predicate} P,

� � � � � �A � P is equal to A iz P is satis{ed and to � otherwise.

We can use predicates like t � u , ¬P or P Q.

The equality type t� u is encoded as � � t� u .


Interpretation of the Function Type

� � � � � � A � B = �x.w | � v � A , w[x� v] � B



� � � � � � A � B = �x.w | � v � A , w[x� v] � B

What about �-abstractions which bodies are terms?



� � � � � � A � B = �x.w | � v � A , w[x� v] � B


�� We de{ne a completion operation A � A .



� � � � � � A � B = �x.w | � v � A , w[x� v] � B



�� The set A contains terms |behaving} as values oz A .



� � � � � � A � B = �x.w | � v � A , w[x� v] � B



�� The set A contains terms |behaving} as values oz A .

�� Dewnition: we take A � B = �x.t | � v � A , t[x� v] � B .


Pole and Orthogonality

�� The de{nition oz A is parametrised by a set oz processes � � �×�.




We require that p � � and q � p implies q � �.





Intuitively, � is a set oz processes that |behave well}.






The set � = p | p� is a good choice.






The set � = p | p� is a good choice.


�A� � ��w�w�v ��v|� ��

�A� � = ��v,�A��v�|��

�A� �� = ��t,�A� ��|��t

Value Restriction and Typing Judgments

Combining call-by-value and efzects leads to soundness issues (well-known).




Usual solution: |value restriction} on some typing rules.





This is encoded with two zorms judgments:

� ; v : A zor values only,val

� ; t : A zor terms (including values).









� ; v : Aval

� ; v : A








�, x : A ; x : Aval

�, x : A ; t : B

� ; �x.t : A � Bval

� ; v : Aval

� ; v : A

� ; t : A � B � ; u : A

� ; t u : B

Adequate Typing Rule

Theorem (adequacy lemma):�� iz t : A is derivable then t � A ,

� �iz v : A is derivable then v � A .val





Proof by induction on the typing derivation.






We only need to check that our typing rules are |correct}.






We only need to check that our typing rules are |correct}.

�� v : Aval � � � �For example is correct since A � A . v : A


Adequacy of For All Introduction

� ; v : Aval X�� ; v : �X.Aval



X v : Aval

v : �X.Aval



X v : Aval

v : �X.Aval

� � � �We suppose v � A[X��] zor all �, and show v � �X.A .



X v : Aval

v : �X.Aval


� � � �This is immediate since �X.A = A[X��] .��



X v : Aval

v : �X.Aval



X t : Abad

t : �X.A



X v : Aval

v : �X.Aval



X t : Abad

t : �X.A

�� We suppose t � A[X��] zor all �, and show t � �X.A .



X v : Aval

v : �X.Aval



X t : Abad

t : �X.A

�� We suppose t � A[X��] zor all �, and show t � �X.A .

�� However we have A[X��] �X.A = A[X��] .� ��


Properties of the System

Theorem (normalisation):�t : A implies t � � � v � � zor some value v.




Theorem (safety for simple datatypes):�t : A implies t � � � v � � zor some value v : A .




Theorem (safety for simple datatypes):�t : A implies t � � � v � � zor some value v : A .

Theorem (consistency):

there is no closed term t :�.


Part III

Semantical Value Restriction


Derived Rules for Dependent Functions

��x : A t : B a � x t : �a�A.B v : Aval

�x.t : �a�A.B t v : B[a� v]val





t : �a�A.B v : AvalDez �i

t : �a.(a�A � B) v : v�Aval� �e

t : v�A � B[a� v] v : v�A�e

t v : B[a� v]





t : �a�A.B v : AvalDez �i

t : �a.(a�A � B) v : v�Aval� �e

t : v�A � B[a� v] v : v�A�e

t v : B[a� v]

Value restriction breaks the compositionality oz dependent zunctions.

// add_n_Zero : �n�nat, add n Zero � n

add_n_Zero (add Zero S[Zero]) : add (add Zero S[Zero]) Zero � add Zero S[Zero]



t : �a�A.B v : A t : �a�A.B u : A u � vvalWe replace by . t v : B[a� v] t u : B[a� u]




v : A t : A t � vvalThis requires changing into . v : v�A t : t�Aval





Can this rule be derived in the system?





Can this rule be derived in the system?

t : A t � v�

v : A

v : Aval �i

v : v�Aval � v : v�A t � v

� t : t�A


Biorthogonal Completion Closed for Values

v : AEverything goes down to having a rule .

v : Aval




v : Aval

v : AvalIt should not be conzused with . v : A




v : Aval


�� Semantically, this requires that v � A implies v � A .




v : Aval



The biorthogonal completion should not introduce new values.




v : Aval



The biorthogonal completion should not introduce new values.

The rule seems reasonable, but it is hard to justizy semantically.


The New Instruction Trick

�� We do not have v � A implies v � A in every reali~ability model.







We extend the system with a new term constructor ! such thatv,w

! � � � v � � ifz v " w.v,w





! � � � v � � ifz v " w.v,w

Idea oz the prooz with � = p | p� :





! � � � v � � ifz v " w.v,w

Idea oz the prooz with � = p | p� :�� We assume v � A and show v � A .





! � � � v � � ifz v " w.v,w


�� We need to {nd � � A such that v � � �.





! � � � v � � ifz v " w.v,w



� �We need to {nd � such that v � � � and �w � A , w � � �.





! � � � v � � ifz v " w.v,w




We can take � = [�x.! ]�.x,v





! � � � v � � ifz v " w.v,w





v � [�x.! ]� � �x.! � v . � � ! � ��x,v x,v v,v





! � � � v � � ifz v " w.v,w





v � [�x.! ]� � �x.! � v . � � ! � ��x,v x,v v,v

� �w � [�x.! ]� � �x.! � w. � � ! � � � w � �� iz w � Ax,v x,v w,v


Well-defined construction of equivalence and reduction

� � � �Problem: the de{nitions oz � and � are circular.


Well-defined construction of equivalence and reduction

� � � �Problem: the de{nitions oz � and � are circular.

We need to rely on a strati{ed construction oz the two relations.

� � � � � �� = � # ! �� , v �� | � j < i , v " wi v,w j

� � � �� = t , u | � j$ i , � � , �%, t%�� u%��i j j

We then take

� � � � � � � �� = � and � = � .i� i�i �� i ��


|Demo} (?) and Conclusion


Things That I did not Show

1) Syntax directed typing and subtyping rules using:

local subtyping judgments oz the zorm t � A & B,

choice operators like � (t �B) or � (t �A),x�A X

an encoding oz |neutral terms} into reduction.

2) Inductive types, coinductive types and recursion (more recent) using:

circular typing and subtyping proozs,

well-zoundedness established using the si{e change principle.

3) Unreachable code and rezutation oz patterns.


Future Work

Practical issues (work in progress):

Composing programs that are proved terminating.

Extensible records and variant types (inzerence).

Toward a practical language:

Compiler using typing inzormations zor optimisations.

Built-in types (int64, �oat) with their speci{cation.

Theoretical questions:

Can we handle more side-efzects? (mutable cells, arrays)

What can we realise with (variations oz) ! ?v,w

Can we extend the system with quotient types?

Can we zormalise mathematics in the system?


References for Technical Details

A Classical Reali{ability Model for a Semantical Value Restriction

R. Lepigre (ESOP 2016)

https://lepigre.zr/{les/docs/lepigre2016_svr.pdz

Practical Subtyping for Curry-Style Languages

R. Lepigre and C. Rafzalli (submitted to TOPLAS)

https://lepigre.zr/{les/docs/lepigre2017_subml.pdz

Semantics and Implementation of an Extension of ML for Proving Programs

R. Lepigre, PhD manuscript

http://lepigre.zr/{les/docs/phd.pdz


Thanks!

Documents

The PML Language · The PML Language: Realizability at the Service of Program Proofs Rodolphe Lepigre Realizability workshop { 08/03/2018 { Marseille. ... give the syntax oz programs