I just got "ML for the working programmer" in the mail a few days ago,

and worked through it at a breakneck pace since receiving it. It

turns out that a lot of the stuff from the "Total Functional

Programming" book is also in this one. Paulson goes through the use

of structural recursion and extends the results by showing techniques

for proving a large class of programs to be terminating. Work with

co-algebras and bi-simulation didn't quite make it in, except for a

brief mention about co-variant types leading to the possibility of a

type: D := D → D which is the type of programs in the untyped lambda

calculus, and hence liable to lead one into trouble.

I have to say that having finished the book, this is the single most

interesting programming book that I've read since "Paradigms of

Artificial Intelligence Programming" and "Structure and Interpretation

of Computer Programs". In fact, I would rate this one above the other

two, though I think it might be because of my current interests.

The conjunction of "Total Functional Programming" and "ML for the

Working Programmer" have completely changed my world view of automated

deduction. Interestingly, my advisers work looks even more appealing

from this perspective.

The basic crux of the issue is this. Given that we restrict ourselves

to total functional programming, as described in the aforementioned

article, we will have the ability to prove theorems directly by

manipulation of the program source.

My adviser told me about this the first time that I met him. It at

first seemed like a curiosity. It has however, blossomed into a

completely different way of thinking about how proofs should be

performed.

I've spent the last few days converting proofs into program source,

which I then manipulate equationally. I have a few examples of

inductive proofs that can be written quite naturally as structurally

recursive functions.

Both of these functions are direct "extractions" of a program from a

proofs that I wrote. The second one is a proof with two existential

variables. The two existential variables present themselves as return

values. In the case of "lt" it simply computes a truth value.

The datatype nat = Z | S of nat defines natural numbers with the

correspondence Z=0, S(Z)=1, S(S(Z))=2 etc...

The proof is a proposition that goes like this:

∀n,d:nat. d>0 ∃q,r:nat. n=dq+r ∧ 0≤r<d

You might notice I dropped the restriction on d in the actual source

code. That can be encoded with an auxiliary function in any case.

The proof proceeds inductively, basically you can turn the divide

function inside out to recover the inductive proof.

The base case is n=0 which gives 0=dq+r which gives r=0 and q=0 (since

d is greater than 0). The first case is exemplified in the case

structure above. (Z,Z) = (q,r) the two existential variables are

returned with a valid result for n=0.

The inductive case is this.

n: ∃q,r. n=dq+r ∧ 0≤r<d

(n+1): ∃q',r'. n+1=dq'+r' ∧ 0≤r'<d

if(r+1)<d

then n+1=dq+r+1

We see that this gives us that r'=r+1, q'=q giving us a solution to r' and q' from r and q (and hence solving the n case, gives us some information about n+1)

else n+1 = d(q+1)+r'

which we can rewrite as: n+1 = d(q+1)+r' = dq+d+r'=dq+r+1 so d+r'=r+1,

but r+1 must be at least d otherwise we wouldn't have failed the test

r+1<d, and r' can be no less than zero, so we must choose r'=0

this results in (finally!)

n+1 = d(q+1) with r'=0,q'=q+1

We have a proof! For the extracted program you can look at the source

and see that in fact it mirrors the proof directly, short of a few

simplifications done by hand. Making use of the r,q in the proof of

r' and q' is the same as my use of r and q in my proof of the n+1 case.

I'm looking forward to a deeper understanding of the correspondences

between proofs and programs with my new found capacity to produce actual functional program proofs by extraction manually. I'm also

curious to try my hand at generating termination proofs directly, and

also at making a syntax that more directly supports total functional

programming.

and worked through it at a breakneck pace since receiving it. It

turns out that a lot of the stuff from the "Total Functional

Programming" book is also in this one. Paulson goes through the use

of structural recursion and extends the results by showing techniques

for proving a large class of programs to be terminating. Work with

co-algebras and bi-simulation didn't quite make it in, except for a

brief mention about co-variant types leading to the possibility of a

type: D := D → D which is the type of programs in the untyped lambda

calculus, and hence liable to lead one into trouble.

I have to say that having finished the book, this is the single most

interesting programming book that I've read since "Paradigms of

Artificial Intelligence Programming" and "Structure and Interpretation

of Computer Programs". In fact, I would rate this one above the other

two, though I think it might be because of my current interests.

The conjunction of "Total Functional Programming" and "ML for the

Working Programmer" have completely changed my world view of automated

deduction. Interestingly, my advisers work looks even more appealing

from this perspective.

The basic crux of the issue is this. Given that we restrict ourselves

to total functional programming, as described in the aforementioned

article, we will have the ability to prove theorems directly by

manipulation of the program source.

My adviser told me about this the first time that I met him. It at

first seemed like a curiosity. It has however, blossomed into a

completely different way of thinking about how proofs should be

performed.

I've spent the last few days converting proofs into program source,

which I then manipulate equationally. I have a few examples of

inductive proofs that can be written quite naturally as structurally

recursive functions.

datatype nat = Z | S of nat fun lt n m = case m of Z => false | (S m') => case n of Z => true | (S n') => lt n' m' fun divide n d = case n of Z => (Z,Z) | (S n') => let val (q',r') = divide n' d in case lt (S r') d of true => (q',S r') | false => (S q',Z) end

Both of these functions are direct "extractions" of a program from a

proofs that I wrote. The second one is a proof with two existential

variables. The two existential variables present themselves as return

values. In the case of "lt" it simply computes a truth value.

The datatype nat = Z | S of nat defines natural numbers with the

correspondence Z=0, S(Z)=1, S(S(Z))=2 etc...

The proof is a proposition that goes like this:

∀n,d:nat. d>0 ∃q,r:nat. n=dq+r ∧ 0≤r<d

You might notice I dropped the restriction on d in the actual source

code. That can be encoded with an auxiliary function in any case.

The proof proceeds inductively, basically you can turn the divide

function inside out to recover the inductive proof.

The base case is n=0 which gives 0=dq+r which gives r=0 and q=0 (since

d is greater than 0). The first case is exemplified in the case

structure above. (Z,Z) = (q,r) the two existential variables are

returned with a valid result for n=0.

The inductive case is this.

n: ∃q,r. n=dq+r ∧ 0≤r<d

(n+1): ∃q',r'. n+1=dq'+r' ∧ 0≤r'<d

if(r+1)<d

then n+1=dq+r+1

We see that this gives us that r'=r+1, q'=q giving us a solution to r' and q' from r and q (and hence solving the n case, gives us some information about n+1)

else n+1 = d(q+1)+r'

which we can rewrite as: n+1 = d(q+1)+r' = dq+d+r'=dq+r+1 so d+r'=r+1,

but r+1 must be at least d otherwise we wouldn't have failed the test

r+1<d, and r' can be no less than zero, so we must choose r'=0

this results in (finally!)

n+1 = d(q+1) with r'=0,q'=q+1

We have a proof! For the extracted program you can look at the source

and see that in fact it mirrors the proof directly, short of a few

simplifications done by hand. Making use of the r,q in the proof of

r' and q' is the same as my use of r and q in my proof of the n+1 case.

I'm looking forward to a deeper understanding of the correspondences

between proofs and programs with my new found capacity to produce actual functional program proofs by extraction manually. I'm also

curious to try my hand at generating termination proofs directly, and

also at making a syntax that more directly supports total functional

programming.

## Comments

## Post a Comment