Concoqtion Implementation News

Emir is working on some important enhancements to concoqtion and hopefully a new version supporting native code and based on the latest OCaml version will be available soon It's half done under Linux but for Mac OS there are still some issues.

Previous Tasks

Unrefined zip

The zip without contect refinement using the trick we talked about on Feb 22nd. Joseph and Jun managed to do it.

Delete on braun trees

Pending till we see if concoqtion will be extended to facilitate writing it without tricks similar to the one in unrefined zip

Staged Interpreters

Using the same calculus as before:

 e::= i| x | \lambda x.e | e e

We can define the following type OCaml

 type exp = Int of int
   | Var of string
   | Lam of string of exp
   | App of exp * exp

using De Bruijn indices the calculus becomes:

 e::= i | #n | \lambda .e | e e

and the OCaml type becomes:

 type exp = Int of int
   | Var of nat
   | Lam of exp
   | App of exp * exp

We will use the first version for now and define the main interpreter function eval as follows:

 let rec eval e env =
   match e with
   | Int i -> i
   | Var x -> env x
   | Lam x e -> (fun v -> eval e (ext env x v))
   | App e1 e2 -> (eval e1 env) (eval e2 env)

we are thinking of env as function that takes a variable name and returns its value

 env: string -> value

and ext as a function that extends that environment with a new variable and its associated value

 ext: (string -> value) -> string -> value -> (string -> value)

The eval as currently defined has a problem. It will not typecheck. The return type of each of the branch function is different. We need to define a new type

 type value =
   | VInt of int
   | VFun of (value -> value)

Now we should be able to redefine eval correctly

 let rec eval e env =
   match e with
   | Int i -> VInt i
   | Var x -> env x
   | Lam x e -> VFun (fun v -> eval e (ext env x v))
   | App e1 e2 -> (unFun(eval e1 env)) (eval e2 env)

and here is the definition of unFun v (needed in the application case in eval):

 let unFun v = 
   match v with
   | VFun f -> f
   | VInt i -> raise Error

Now eval is typed

 eval: exp -> (string->value)->value

The problem with this cool way of implementing the interpreter is that it is really slow. The running time of a program written in the language we are interpreting and using the eval as defined above is much much bigger than the running time of the same program if it was directly written in ocaml.

The long time is due to 2 costs

"value" delays
"lambda-value" delays

Example

Using our eval to evaluate "lambda x.x" we get:

 eval "lambda x.x" env -> VFun (fun v-> eval "x" (ext env x v) -> VFun (fun v. v)

Instead of getting "lambda x.x" directly Here the "value" delay comes from adding VFun to the result and the "lambda-value" delay comes from the recursive call to "eval" Getting rid of these 2 delays, what you get is a compiler not really an interpreter and that's what we try to do using staged interpreters.

Homework