(***************************************************************** 

  Nominal Isabelle Tutorial

  -------------------------

  11th August 2008, Sydney 

  This file contains most of the material that will be covered in the 

  tutorial. The file can be "stepped through"; though it contains much 

  commented code (purple text). 

*)

(***************************************************************** 

  Proof General

  -------------

  Proof General is the front end for Isabelle.

  To run Nominal Isabelle proof-scripts you must have HOL-Nominal enabled in

  the menu Isabelle -> Logics. You also need to enable X-Symbols in the menu 

  Proof-General -> Options (make sure to save this option once enabled).

  Proof General "paints" blue the part of the proof-script that has already

  been processed by Isabelle. You can advance or retract the "frontier" of

  this processed part using the "Next" and "Undo" buttons in the

  menubar. "Goto" will process everything up to the current cursor position,

  or retract if the cursor is inside the blue part. The key-combination

  control-c control-return is a short-cut for the "Goto"-operation.

  Proof General gives feedback inside the "Response" and "Goals" buffers.

  The response buffer will contain warning messages (in yellow) and 

  error messages (in red). Warning messages can generally be ignored. Error 

  messages must be dealt with in order to advance the proof script. The goal 

  buffer shows which goals need to be proved. The sole idea of interactive 

  theorem proving is to get the message "No subgoals." ;o)

*)

(***************************************************************** 

  X-Symbols

  ---------

  X-symbols provide a nice way to input non-ascii characters. For example:

  \<forall>, \<exists>, \<Down>, \<sharp>, \<And>, \<Gamma>, \<times>, \<noteq>, \<in>, \<subseteq>, \<dots>

  They need to be input via the combination \<name-of-x-symbol> 

  where name-of-x-symbol coincides with the usual latex name of

  that symbol.

  However, there are some handy short-cuts for frequently used X-symbols. 

  For example

  [|  \<dots> \<lbrakk> 

  |]  \<dots> \<rbrakk> 

  ==> \<dots> \<Longrightarrow> 

  =>  \<dots> \<Rightarrow> 

  --> \<dots> \<longrightarrow> 

  /\  \<dots> \<and>

  \/  \<dots> \<or> 

  |-> \<dots> \<mapsto>

  =_  \<dots> \<equiv>    

*)

(***************************************************************** 

  Theories

  --------

  Every Isabelle proof-script needs to have a name and must import

  some pre-existing theory. For Nominal Isabelle proof-scripts this will 

  normally be the theory Nominal, but we use here the theory Lambda.thy, 

  which extends Nominal with a definition for lambda-terms and capture-

  avoiding substitution.

  BTW, the Nominal theory builds directly on Isabelle/HOL and extends it

  only with some definitions and some reasoning infrastructure. It does not 

  add any new axiom to Isabelle/HOL. So you can trust what you are doing. ;o)

*)

theory CK_Machine

  imports "Lambda" 

begin

text {***************************************************************** 

  Types

  -----

  Isabelle is based, roughly, on the theory of simple types including some 

  polymorphism. It also includes some overloading, which means that sometimes 

  explicit type annotations need to be given.

  - Base types include: nat, bool, string, lam 

  - Type formers include: 'a list, ('a\<times>'b), 'c set   

  - Type variables are written like in ML with an apostrophe: 'a, 'b, \<dots>

  Types known to Isabelle can be queried using:

*}

typ nat

typ bool

typ lam              (* the type for alpha-equated lambda-terms *)

typ "('a \<times> 'b)"      (* product type *)

typ "'c set"         (* set type *)

typ "nat \<Rightarrow> bool"    (* the type for functions from nat to bool *)

(* These give errors: *)

(*typ boolean *) 

(*typ set*)

text {***************************************************************** 

   Terms

   -----

   Every term in Isabelle needs to be well-typed (however they can have polymorphic

   type). Whether a term is accepted can be queried using: 

*}

term c                 (* a variable of polymorphic type *)

term "1::nat"          (* the constant 1 in natural numbers *)

term 1                 (* the constant 1 with polymorphic type *)          

term "{1, 2, 3::nat}"  (* the set containing natural numbers 1, 2 and 3 *)      

term "[1, 2, 3]"       (* the list containing the polymorphic numbers 1, 2 and 3 *)  

term "Lam [x].(Var x)" (* a lambda-term *)

term "App t1 t2"       (* another lambda-term *)

text {* 

  Isabelle provides some useful colour feedback about what are constants (in black),

  free variables (in blue) and bound variables (in green). *}

term "True"     (* a constant that is defined in HOL *)

term "true"     (* not recognised as a constant, therefore it is interpreted as a variable *)

term "\<forall>x. P x"  (* x is bound, P is free *)

text {* Every formula in Isabelle needs to have type bool *}

term "True"

term "True \<and> False"

term "{1,2,3} = {3,2,1}"

term "\<forall>x. P x"

term "A \<longrightarrow> B"

text {* 

  When working with Isabelle, one is confronted with an object logic (that is HOL)

  and Isabelle's meta-logic (called Pure). Sometimes one has to pay attention 

  to this fact. *}

term "A \<longrightarrow> B" (* versus *)

term "A \<Longrightarrow> B"

term "\<forall>x. P x" (* versus *)

term "\<And>x. P x"

term "A \<Longrightarrow> B \<Longrightarrow> C" (* is synonymous with *)

term "\<lbrakk>A; B\<rbrakk> \<Longrightarrow> C"

text {***************************************************************** 

  Inductive Definitions: The Evaluation Judgement and the Value Predicate

  -----------------------------------------------------------------------

  Inductive definitions start with the keyword "inductive" and a predicate name. 

  One also needs to provide a type for the predicate. Clauses of the inductive

  predicate are introduced by "where" and more than two clauses need to be 

  separated by "|". Optionally one can give a name to each clause and indicate 

  that it should be added to the hints database ("[intro]"). A typical clause

  has some premises and a conclusion. This is written in Isabelle as:

  "premise \<Longrightarrow> conclusion"

  "\<lbrakk>premise1; premise2; \<dots> \<rbrakk> \<Longrightarrow> conclusion"

  If no premise is present, then one just writes

  "conclusion"

  Below we define the evaluation judgement for lambda-terms. This definition 

  introduces the predicate named "eval". After giving its type, we declare 

  the usual pretty syntax _ \<Down> _. In this declaration _ stands for an argument

  of eval.

*}

inductive

  eval :: "lam \<Rightarrow> lam \<Rightarrow> bool" ("_ \<Down> _") 

where

  e_Lam:  "Lam [x].t \<Down> Lam [x].t"

| e_App:  "\<lbrakk>t1 \<Down> Lam [x].t; t2 \<Down> v'; t[x::=v'] \<Down> v\<rbrakk> \<Longrightarrow> App t1 t2 \<Down> v"

declare eval.intros[intro]

text {* 

  Values are also defined using inductive. In our case values

  are just lambda-abstractions. *}

inductive

  val :: "lam \<Rightarrow> bool" 

where

  v_Lam[intro]:   "val (Lam [x].t)"

text {***************************************************************** 

  Theorems

  --------

  A central concept in Isabelle is that of theorems. Isabelle's theorem

  database can be queried using 

*}

thm e_Lam

thm e_App

thm conjI

thm conjunct1

text {* 

  Notice that theorems usually contain schematic variables (e.g. ?P, ?Q, \<dots>). 

  These schematic variables can be substituted with any term (of the right type 

  of course). It is sometimes useful to suppress the "?" from the schematic 

  variables. This can be achieved by using the attribute "[no_vars]". *}

thm e_Lam[no_vars]

thm e_App[no_vars]

thm conjI[no_vars]

thm conjunct1[no_vars]

text {* 

  When defining the predicate eval, Isabelle provides us automatically with 

  the following theorems that state how evaluation judgments can be introduced 

  and what constitutes an induction over the predicate eval. *}

thm eval.intros[no_vars]

thm eval.induct[no_vars]

text {***************************************************************** 

  Lemma / Theorem / Corollary Statements 

  --------------------------------------

  Whether to use lemma, theorem or corollary makes no semantic difference 

  in Isabelle. A lemma starts with "lemma" and consists of a statement 

  ("shows \<dots>") and optionally a lemma name, some type-information for 

  variables ("fixes \<dots>") and some assumptions ("assumes \<dots>"). Lemmas 

  also need to have a proof, but ignore this 'detail' for the moment.

*}

lemma alpha_equ:

  shows "Lam [x].Var x = Lam [y].Var y"

by (simp add: lam.inject alpha swap_simps fresh_atm)

lemma Lam_freshness:

  assumes a: "x\<noteq>y"

  shows "y\<sharp>Lam [x].t \<Longrightarrow> y\<sharp>t"

using a by (simp add: abs_fresh) 

lemma neutral_element:

  fixes x::"nat"

  shows "x + 0 = x"

by simp

text {***************************************************************** 

  Datatypes: Evaluation Contexts 

  ------------------------------

  Datatypes can be defined in Isabelle as follows: we have to provide the name 

  of the datatype and list its type-constructors. Each type-constructor needs 

  to have the information about the types of its arguments, and optionally 

  can also contain some information about pretty syntax. For example, we like

  to write "\<box>" for holes.

*}

datatype ctx = 

    Hole ("\<box>")  

  | CAppL "ctx" "lam"

  | CAppR "lam" "ctx"

text {* Now Isabelle knows about: *}

typ ctx

term "\<box>"

term "CAppL"

term "CAppL \<box> (Var x)"

text {* 

  1.) MINI EXERCISE

  -----------------

  Try and see what happens if you apply a Hole to a Hole? 

*}

text {***************************************************************** 

  The CK Machine

  --------------

  The CK machine is also defined using an inductive predicate with four

  arguments. The idea behind this abstract machine is to transform, or reduce, 

  a configuration consisting of a lambda-term and a framestack (a list of 

  contexts), to a new configuration.

  We use the type abbreviation "ctxs" for the type for framestacks. 

  The pretty syntax for the CK machine is <_,_> \<mapsto> <_,_>.

*}

types ctxs = "ctx list"

inductive

  machine :: "lam \<Rightarrow> ctxs \<Rightarrow>lam \<Rightarrow> ctxs \<Rightarrow> bool" ("<_,_> \<mapsto> <_,_>")

where

  m1[intro]: "<App t1 t2,Es> \<mapsto> <t1,(CAppL \<box> t2)#Es>"

| m2[intro]: "val v \<Longrightarrow> <v,(CAppL \<box> t2)#Es> \<mapsto> <t2,(CAppR v \<box>)#Es>"

| m3[intro]: "val v \<Longrightarrow> <v,(CAppR (Lam [x].t) \<box>)#Es> \<mapsto> <t[x::=v],Es>"

text {*

  Since the machine defined above only performs a single reduction,

  we need to define the transitive closure of this machine. *}

inductive 

  machines :: "lam \<Rightarrow> ctxs \<Rightarrow> lam \<Rightarrow> ctxs \<Rightarrow> bool" ("<_,_> \<mapsto>* <_,_>")

where

  ms1[intro]: "<t,Es> \<mapsto>* <t,Es>"

| ms2[intro]: "\<lbrakk><t1,Es1> \<mapsto> <t2,Es2>; <t2,Es2> \<mapsto>* <t3,Es3>\<rbrakk> \<Longrightarrow> <t1,Es1> \<mapsto>* <t3,Es3>"

text {***************************************************************** 

  Isar Proofs

  -----------

  Isar is a language for writing down proofs that can be understood by humans 

  and by Isabelle. An Isar proof can be thought of as a sequence of 'stepping stones' 

  that start with the assumptions and lead to the goal to be established. Every such 

  stepping stone is introduced by "have" followed by the statement of the stepping 

  stone. An exception is the goal to be proved, which need to be introduced with "show".

  Since proofs usually do not proceed in a linear fashion, a label can be given 

  to each stepping stone and then used later to refer to this stepping stone 

  ("using").

  Each stepping stone (or have-statement) needs to have a justification. The 

  simplest justification is "sorry" which admits any stepping stone, even false 

  ones (this is good during the development of proofs). Assumption can be 

  "justified" using "by fact". Derived facts can be justified using 

  - by simp    (* simplification *)

  - by auto    (* proof search and simplification *)

  - by blast   (* only proof search *)

  If facts or lemmas are needed in order to justify a have-statement, then

  one can feed these facts into the proof by using "using label \<dots>" or 

  "using theorem-name \<dots>". More than one label at the time is allowed.

  Induction proofs in Isar are set up by indicating over which predicate(s) 

  the induction proceeds ("using a b") followed by the command "proof (induct)". 

  In this way, Isabelle uses default settings for which induction should

  be performed. These default settings can be overridden by giving more

  information, like the variable over which a structural induction should

  proceed, or a specific induction principle such as well-founded inductions. 

  After the induction is set up, the proof proceeds by cases. In Isar these 

  cases can be given in any order, but must be started with "case" and the 

  name of the case, and optionally some legible names for the variables 

  referred to inside the case. 

  The possible case-names can be found by looking inside the menu "Isabelle -> 

  Show me -> cases". In each "case", we need to establish a statement introduced 

  by "show". Once this has been done, the next case can be started using "next". 

  When all cases are completed, the proof can be finished using "qed".

  This means a typical induction proof has the following pattern

     proof (induct)

       case \<dots>

       \<dots>

       show \<dots>

     next

       case \<dots>

       \<dots>

       show \<dots>

     \<dots>

     qed

  The four lemmas are by induction on the predicate machines. All proofs establish 

  the same property, namely a transitivity rule for machines. The complete Isar 

  proofs are given for the first three proofs. The point of these three proofs is 

  that each proof increases the readability for humans. 

*}

text {***************************************************************** 

  2.) EXERCISE

  ------------

  Remove the sorries in the proof below and fill in the correct 

  justifications. 

*}

lemma 

  assumes a: "<e1,Es1> \<mapsto>* <e2,Es2>" 

  and     b: "<e2,Es2> \<mapsto>* <e3,Es3>"

  shows "<e1,Es1> \<mapsto>* <e3,Es3>"

using a b

proof(induct)

  case (ms1 e1 Es1)

  have c: "<e1,Es1> \<mapsto>* <e3,Es3>" by fact

  show "<e1,Es1> \<mapsto>* <e3,Es3>" sorry

next

  case (ms2 e1 Es1 e2 Es2 e2' Es2') 

  have ih: "<e2',Es2'> \<mapsto>* <e3,Es3> \<Longrightarrow> <e2,Es2> \<mapsto>* <e3,Es3>" by fact

  have d1: "<e2',Es2'> \<mapsto>* <e3,Es3>" by fact

  have d2: "<e1,Es1> \<mapsto> <e2,Es2>" by fact

  show "<e1,Es1> \<mapsto>* <e3,Es3>" sorry

qed

text {* 

  Just like gotos in the Basic programming language, labels can reduce 

  the readability of proofs. Therefore one can use in Isar the notation

  "then have" in order to feed a have-statement to the proof of 

  the next have-statement. In the proof below this has been used

  in order to get rid of the labels c and d1. 

*}

lemma 

  assumes a: "<e1,Es1> \<mapsto>* <e2,Es2>" 

  and     b: "<e2,Es2> \<mapsto>* <e3,Es3>"

  shows "<e1,Es1> \<mapsto>* <e3,Es3>"

using a b

proof(induct)

  case (ms1 e1 Es1)

  show "<e1,Es1> \<mapsto>* <e3,Es3>" by fact

next

  case (ms2 e1 Es1 e2 Es2 e2' Es2')

  have ih: "<e2',Es2'> \<mapsto>* <e3,Es3> \<Longrightarrow> <e2,Es2> \<mapsto>* <e3,Es3>" by fact

  have "<e2',Es2'> \<mapsto>* <e3,Es3>" by fact

  then have d3: "<e2,Es2> \<mapsto>* <e3,Es3>" using ih by simp

  have d2: "<e1,Es1> \<mapsto> <e2,Es2>" by fact

  show "<e1,Es1> \<mapsto>* <e3,Es3>" using d2 d3 by auto

qed

text {* 

  The labels d2 and d3 cannot be got rid of in this way, because both 

  facts are needed to prove the show-statement. We can still avoid the

  labels by feeding a sequence of facts into a proof using the chaining

  mechanism:

   have "statement1" \<dots>

   moreover

   have "statement2" \<dots>

   \<dots>

   moreover

   have "statementn" \<dots>

   ultimately have "statement" \<dots>

  In this chain, all "statementi" can be used in the proof of the final 

  "statement". With this we can simplify our proof further to:

*}

lemma 

  assumes a: "<e1,Es1> \<mapsto>* <e2,Es2>" 

  and     b: "<e2,Es2> \<mapsto>* <e3,Es3>"

  shows "<e1,Es1> \<mapsto>* <e3,Es3>"

using a b

proof(induct)

  case (ms1 e1 Es1)

  show "<e1,Es1> \<mapsto>* <e3,Es3>" by fact

next

  case (ms2 e1 Es1 e2 Es2 e2' Es2')

  have ih: "<e2',Es2'> \<mapsto>* <e3,Es3> \<Longrightarrow> <e2,Es2> \<mapsto>* <e3,Es3>" by fact

  have "<e2',Es2'> \<mapsto>* <e3,Es3>" by fact

  then have "<e2,Es2> \<mapsto>* <e3,Es3>" using ih by simp

  moreover

  have "<e1,Es1> \<mapsto> <e2,Es2>" by fact

  ultimately show "<e1,Es1> \<mapsto>* <e3,Es3>" by auto

qed

text {* 

  While automatic proof procedures in Isabelle are not able to prove statements

  like "P = NP" assuming usual definitions for P and NP, they can automatically

  discharge the lemma we just proved. For this we only have to set up the induction

  and auto will take care of the rest. This means we can write:

*}

lemma ms3[intro]:

  assumes a: "<e1,Es1> \<mapsto>* <e2,Es2>" 

  and     b: "<e2,Es2> \<mapsto>* <e3,Es3>"

  shows "<e1,Es1> \<mapsto>* <e3,Es3>"

using a b by (induct) (auto)

text {* 

  The attribute [intro] indicates that this lemma should be from now on used in

  any proof obtained by "auto" or "blast". 

*}

text {***************************************************************** 

  A simple fact we need later on is that if t \<Down> t' then t' is a value. 

*}

lemma eval_to_val:

  assumes a: "t \<Down> t'"

  shows "val t'"