(*<*)

theory Paper

imports "Quotient"

        "LaTeXsugar"

        "../Nominal/FSet"

begin

(****

** things to do for the next version

*

* - what are quot_thms?

* - what do all preservation theorems look like,

    in particular preservation for quotient

    compositions

  - explain how Quotient R Abs Rep is proved (j-version)

  - give an example where precise specification helps (core Haskell in nominal?)

  - Quote from Peter:

    One might think quotient have been studied to death, but

*)

notation (latex output)

  rel_conj ("_ \<circ>\<circ>\<circ> _" [53, 53] 52) and

  pred_comp ("_ \<circ>\<circ> _" [1, 1] 30) and

  "op -->" (infix "\<longrightarrow>" 100) and

  "==>" (infix "\<Longrightarrow>" 100) and

  fun_map ("_ \<^raw:\mbox{\singlearr}> _" 51) and

  fun_rel ("_ \<^raw:\mbox{\doublearr}> _" 51) and

  list_eq (infix "\<approx>" 50) and (* Not sure if we want this notation...? *)

  fempty ("\<emptyset>") and

  funion ("_ \<union> _") and

  finsert ("{_} \<union> _") and 

  Cons ("_::_") and

  concat ("flat") and

  fconcat ("\<Union>")

ML {*

fun nth_conj n (_, r) = nth (HOLogic.dest_conj r) n;

fun style_lhs_rhs proj = Scan.succeed (fn ctxt => fn t =>

  let

    val concl =

      Object_Logic.drop_judgment (ProofContext.theory_of ctxt) (Logic.strip_imp_concl t)

  in

    case concl of (_ $ l $ r) => proj (l, r)

    | _ => error ("Binary operator expected in term: " ^ Syntax.string_of_term ctxt concl)

  end);

*}

setup {*

  Term_Style.setup "rhs1" (style_lhs_rhs (nth_conj 0)) #>

  Term_Style.setup "rhs2" (style_lhs_rhs (nth_conj 1)) #>

  Term_Style.setup "rhs3" (style_lhs_rhs (nth_conj 2))

*}

(*>*)

section {* Introduction *}

text {* 

   \begin{flushright}

  {\em ``Not using a [quotient] package has its advantages: we do not have to\\ 

    collect all the theorems we shall ever want into one giant list;''}\\

    Larry Paulson \cite{Paulson06}

  \end{flushright}

  \noindent

  Isabelle is a popular generic theorem prover in which many logics can be

  implemented. The most widely used one, however, is Higher-Order Logic

  (HOL). This logic consists of a small number of axioms and inference rules

  over a simply-typed term-language. Safe reasoning in HOL is ensured by two

  very restricted mechanisms for extending the logic: one is the definition of

  new constants in terms of existing ones; the other is the introduction of

  new types by identifying non-empty subsets in existing types. It is well

  understood how to use both mechanisms for dealing with quotient

  constructions in HOL (see \cite{Homeier05,Paulson06}).  For example the

  integers in Isabelle/HOL are constructed by a quotient construction over the

  type @{typ "nat \<times> nat"} and the equivalence relation

  \begin{isabelle}\ \ \ \ \ \ \ \ \ \ %%%

  @{text "(n\<^isub>1, n\<^isub>2) \<approx> (m\<^isub>1, m\<^isub>2) \<equiv> n\<^isub>1 + m\<^isub>2 = m\<^isub>1 + n\<^isub>2"}\hfill\numbered{natpairequiv}

  \end{isabelle}

  \noindent

  This constructions yields the new type @{typ int} and definitions for @{text

  "0"} and @{text "1"} of type @{typ int} can be given in terms of pairs of

  natural numbers (namely @{text "(0, 0)"} and @{text "(1, 0)"}). Operations

  such as @{text "add"} with type @{typ "int \<Rightarrow> int \<Rightarrow> int"} can be defined in

  terms of operations on pairs of natural numbers (namely @{text

  "add_pair (n\<^isub>1, m\<^isub>1) (n\<^isub>2,

  m\<^isub>2) \<equiv> (n\<^isub>1 + n\<^isub>2, m\<^isub>1 + m\<^isub>2)"}).

  Similarly one can construct the type of finite sets, written @{term "\<alpha> fset"}, 

  by quotienting the type @{text "\<alpha> list"} according to the equivalence relation

  \begin{isabelle}\ \ \ \ \ \ \ \ \ \ %%%

  @{text "xs \<approx> ys \<equiv> (\<forall>x. memb x xs \<longleftrightarrow> memb x ys)"}\hfill\numbered{listequiv}

  \end{isabelle}

  \noindent

  which states that two lists are equivalent if every element in one list is

  also member in the other. The empty finite set, written @{term "{||}"}, can

  then be defined as the empty list and the union of two finite sets, written

  @{text "\<union>"}, as list append.

  Quotients are important in a variety of areas, but they are really ubiquitous in

  the area of reasoning about programming language calculi. A simple example

  is the lambda-calculus, whose raw terms are defined as

  \begin{isabelle}\ \ \ \ \ \ \ \ \ \ %%%

  @{text "t ::= x | t t | \<lambda>x.t"}\hfill\numbered{lambda}

  \end{isabelle}

  \noindent

  The problem with this definition arises, for instance, when one attempts to

  prove formally the substitution lemma \cite{Barendregt81} by induction

  over the structure of terms. This can be fiendishly complicated (see

  \cite[Pages 94--104]{CurryFeys58} for some ``rough'' sketches of a proof

  about raw lambda-terms). In contrast, if we reason about

  $\alpha$-equated lambda-terms, that means terms quotient according to

  $\alpha$-equivalence, then the reasoning infrastructure provided, 

  for example, by Nominal Isabelle \cite{UrbanKaliszyk11} makes the formal 

  proof of the substitution lemma almost trivial. 

  The difficulty is that in order to be able to reason about integers, finite

  sets or $\alpha$-equated lambda-terms one needs to establish a reasoning

  infrastructure by transferring, or \emph{lifting}, definitions and theorems

  from the raw type @{typ "nat \<times> nat"} to the quotient type @{typ int}

  (similarly for finite sets and $\alpha$-equated lambda-terms). This lifting

  usually requires a \emph{lot} of tedious reasoning effort \cite{Paulson06}.  

  It is feasible to do this work manually, if one has only a few quotient

  constructions at hand. But if they have to be done over and over again, as in 

  Nominal Isabelle, then manual reasoning is not an option.

  The purpose of a \emph{quotient package} is to ease the lifting of theorems

  and automate the reasoning as much as possible. In the

  context of HOL, there have been a few quotient packages already

  \cite{harrison-thesis,Slotosch97}. The most notable one is by Homeier

  \cite{Homeier05} implemented in HOL4.  The fundamental construction these

  quotient packages perform can be illustrated by the following picture:

  \begin{center}

  \mbox{}\hspace{20mm}\begin{tikzpicture}

  %%\draw[step=2mm] (-4,-1) grid (4,1);

  \draw[very thick] (0.7,0.3) circle (4.85mm);

  \draw[rounded corners=1mm, very thick] ( 0.0,-0.9) rectangle ( 1.8, 0.9);

  \draw[rounded corners=1mm, very thick] (-1.95,0.8) rectangle (-2.9,-0.195);

  \draw (-2.0, 0.8) --  (0.7,0.8);

  \draw (-2.0,-0.195)  -- (0.7,-0.195);

  \draw ( 0.7, 0.23) node {\begin{tabular}{@ {}c@ {}}equiv-\\[-1mm]clas.\end{tabular}};

  \draw (-2.45, 0.35) node {\begin{tabular}{@ {}c@ {}}new\\[-1mm]type\end{tabular}};

  \draw (1.8, 0.35) node[right=-0.1mm]

    {\begin{tabular}{@ {}l@ {}}existing\\[-1mm] type\\ (sets of raw elements)\end{tabular}};

  \draw (0.9, -0.55) node {\begin{tabular}{@ {}l@ {}}non-empty\\[-1mm]subset\end{tabular}};

  \draw[->, very thick] (-1.8, 0.36) -- (-0.1,0.36);

  \draw[<-, very thick] (-1.8, 0.16) -- (-0.1,0.16);

  \draw (-0.95, 0.26) node[above=0.4mm] {@{text Rep}};

  \draw (-0.95, 0.26) node[below=0.4mm] {@{text Abs}};

  \end{tikzpicture}

  \end{center}

  \noindent

  The starting point is an existing type, to which we refer as the

  \emph{raw type} and over which an equivalence relation given by the user is

  defined. With this input the package introduces a new type, to which we

  refer as the \emph{quotient type}. This type comes with an

  \emph{abstraction} and a \emph{representation} function, written @{text Abs}

  and @{text Rep}.\footnote{Actually slightly more basic functions are given;

  the functions @{text Abs} and @{text Rep} need to be derived from them. We

  will show the details later. } They relate elements in the

  existing type to elements in the new type and vice versa, and can be uniquely

  identified by their quotient type. For example for the integer quotient construction

  the types of @{text Abs} and @{text Rep} are

  \begin{isabelle}\ \ \ \ \ \ \ \ \ \ %%%

  @{text "Abs :: nat \<times> nat \<Rightarrow> int"}\hspace{10mm}@{text "Rep :: int \<Rightarrow> nat \<times> nat"}

  \end{isabelle}

  \noindent

  We therefore often write @{text Abs_int} and @{text Rep_int} if the

  typing information is important. 

  Every abstraction and representation function stands for an isomorphism

  between the non-empty subset and elements in the new type. They are

  necessary for making definitions involving the new type. For example @{text

  "0"} and @{text "1"} of type @{typ int} can be defined as

  \begin{isabelle}\ \ \ \ \ \ \ \ \ \ %%%

  @{text "0 \<equiv> Abs_int (0, 0)"}\hspace{10mm}@{text "1 \<equiv> Abs_int (1, 0)"}

  \end{isabelle}

  \noindent

  Slightly more complicated is the definition of @{text "add"} having type 

  @{typ "int \<Rightarrow> int \<Rightarrow> int"}. Its definition is as follows

   \begin{isabelle}\ \ \ \ \ \ \ \ \ \ %%%

  @{text "add n m \<equiv> Abs_int (add_pair (Rep_int n) (Rep_int m))"}

  \hfill\numbered{adddef}

  \end{isabelle}

  \noindent

  where we take the representation of the arguments @{text n} and @{text m},

  add them according to the function @{text "add_pair"} and then take the

  abstraction of the result.  This is all straightforward and the existing

  quotient packages can deal with such definitions. But what is surprising

  that none of them can deal with slightly more complicated definitions involving

  \emph{compositions} of quotients. Such compositions are needed for example

  in case of quotienting lists to yield finite sets and the operator that 

  flattens lists of lists, defined as follows

  @{thm [display, indent=10] concat.simps(1) concat.simps(2)[no_vars]}

  \noindent

  We expect that the corresponding operator on finite sets, written @{term "fconcat"},

  builds finite unions of finite sets:

  @{thm [display, indent=10] fconcat_empty[no_vars] fconcat_insert[no_vars]}

  \noindent

  The quotient package should automatically provide us with a definition for @{text "\<Union>"} in

  terms of @{text flat}, @{text Rep_fset} and @{text Abs_fset}. The problem is 

  that the method  used in the existing quotient

  packages of just taking the representation of the arguments and then taking

  the abstraction of the result is \emph{not} enough. The reason is that in case

  of @{text "\<Union>"} we obtain the incorrect definition

  @{text [display, indent=10] "\<Union> S \<equiv> Abs_fset (flat (Rep_fset S))"}

  \noindent

  where the right-hand side is not even typable! This problem can be remedied in the

  existing quotient packages by introducing an intermediate step and reasoning

  about flattening of lists of finite sets. However, this remedy is rather

  cumbersome and inelegant in light of our work, which can deal with such

  definitions directly. The solution is that we need to build aggregate

  representation and abstraction functions, which in case of @{text "\<Union>"}

  generate the following definition

  @{text [display, indent=10] "\<Union> S \<equiv> Abs_fset (flat ((map_list Rep_fset \<circ> Rep_fset) S))"}

  \noindent

  where @{term map_list} is the usual mapping function for lists. In this paper we

  will present a formal definition of our aggregate abstraction and

  representation functions (this definition was omitted in \cite{Homeier05}). 

  They generate definitions, like the one above for @{text "\<Union>"}, 

  according to the type of the raw constant and the type

  of the quotient constant. This means we also have to extend the notions

  of \emph{aggregate equivalence relation}, \emph{respectfulness} and \emph{preservation}

  from Homeier \cite{Homeier05}.

  In addition we are able to address the criticism by Paulson \cite{Paulson06} cited

  at the beginning of this section about having to collect theorems that are

  lifted from the raw level to the quotient level into one giant list. Homeier's and

  also our quotient package are modular so that they allow lifting

  theorems separately. This has the advantage for the user of being able to develop a

  formal theory interactively as a natural progression. A pleasing side-result of

  the modularity is that we are able to clearly specify what is involved

  in the lifting process (this was only hinted at in \cite{Homeier05} and

  implemented as a ``rough recipe'' in ML-code).

  The paper is organised as follows: Section \ref{sec:prelims} presents briefly

  some necessary preliminaries; Section \ref{sec:type} describes the definitions 

  of quotient types and shows how definitions of constants can be made over 

  quotient types. Section \ref{sec:resp} introduces the notions of respectfulness

  and preservation; Section \ref{sec:lift} describes the lifting of theorems;

  Section \ref{sec:examples} presents some examples

  and Section \ref{sec:conc} concludes and compares our results to existing 

  work.

*}

section {* Preliminaries and General Quotients\label{sec:prelims} *}

text {*

  We give in this section a crude overview of HOL and describe the main

  definitions given by Homeier for quotients \cite{Homeier05}.

  At its core, HOL is based on a simply-typed term language, where types are 

  recorded in Church-style fashion (that means, we can always infer the type of 

  a term and its subterms without any additional information). The grammars

  for types and terms are as follows

  \begin{isabelle}\ \ \ \ \ \ \ \ \ \ %%%

  \begin{tabular}{@ {}rl@ {\hspace{3mm}}l@ {}}

  @{text "\<sigma>, \<tau> ::="} & @{text "\<alpha> | (\<sigma>,\<dots>, \<sigma>) \<kappa>"} & (type variables and type constructors)\\

  @{text "t, s ::="} & @{text "x\<^isup>\<sigma> | c\<^isup>\<sigma> | t t | \<lambda>x\<^isup>\<sigma>. t"} & 

  (variables, constants, applications and abstractions)\\

  \end{tabular}

  \end{isabelle}

  \noindent

  We often write just @{text \<kappa>} for @{text "() \<kappa>"}, and use @{text "\<alpha>s"} and

  @{text "\<sigma>s"} to stand for collections of type variables and types,

  respectively.  The type of a term is often made explicit by writing @{text

  "t :: \<sigma>"}. HOL includes a type @{typ bool} for booleans and the function

  type, written @{text "\<sigma> \<Rightarrow> \<tau>"}. HOL also contains many primitive and defined

  constants; for example, a primitive constant is equality, with type @{text "= :: \<sigma> \<Rightarrow> \<sigma> \<Rightarrow>

  bool"}, and the identity function with type @{text "id :: \<sigma> \<Rightarrow> \<sigma>"} is

  defined as @{text "\<lambda>x\<^sup>\<sigma>. x\<^sup>\<sigma>"}.

  An important point to note is that theorems in HOL can be seen as a subset

  of terms that are constructed specially (namely through axioms and proof

  rules). As a result we are able to define automatic proof

  procedures showing that one theorem implies another by decomposing the term

  underlying the first theorem.

  Like Homeier's, our work relies on map-functions defined for every type

  constructor taking some arguments, for example @{text map_list} for lists. Homeier

  describes in \cite{Homeier05} map-functions for products, sums, options and

  also the following map for function types

  @{thm [display, indent=10] fun_map_def[no_vars, THEN eq_reflection]}

  \noindent

  Using this map-function, we can give the following, equivalent, but more 

  uniform definition for @{text add} shown in \eqref{adddef}:

  @{text [display, indent=10] "add \<equiv> (Rep_int \<singlearr> Rep_int \<singlearr> Abs_int) add_pair"}

  \noindent

  Using extensionality and unfolding the definition of @{text "\<singlearr>"}, 

  we can get back to \eqref{adddef}. 

  In what follows we shall use the convention to write @{text "map_\<kappa>"} for a map-function 

  of the type-constructor @{text \<kappa>}. In our implementation we maintain 

  a database of these map-functions that can be dynamically extended.

  It will also be necessary to have operators, referred to as @{text "rel_\<kappa>"},

  which define equivalence relations in terms of constituent equivalence

  relations. For example given two equivalence relations @{text "R\<^isub>1"}

  and @{text "R\<^isub>2"}, we can define an equivalence relations over 

  products as follows

  %

  @{text [display, indent=10] "(R\<^isub>1 \<tripple> R\<^isub>2) (x\<^isub>1, x\<^isub>2) (y\<^isub>1, y\<^isub>2) \<equiv> R\<^isub>1 x\<^isub>1 y\<^isub>1 \<and> R\<^isub>2 x\<^isub>2 y\<^isub>2"}

  \noindent

  Homeier gives also the following operator for defining equivalence 

  relations over function types

  %

  \begin{isabelle}\ \ \ \ \ \ \ \ \ \ %%%

  @{thm fun_rel_def[of "R\<^isub>1" "R\<^isub>2", no_vars, THEN eq_reflection]}

  \hfill\numbered{relfun}

  \end{isabelle}

  \noindent

  In the context of quotients, the following two notions from \cite{Homeier05} 

  are needed later on.

  \begin{definition}[Respects]\label{def:respects}

  An element @{text "x"} respects a relation @{text "R"} provided @{text "R x x"}.

  \end{definition}

  \begin{definition}[Bounded Quantification and Bounded Abstractions]\label{def:babs}

  @{text "\<forall>x \<in> S. P x"} holds if for all @{text x}, @{text "x \<in> S"} implies @{text "P x"};

  and @{text "(\<lambda>x \<in> S. f x) = f x"} provided @{text "x \<in> S"}.

  \end{definition}

  The central definition in Homeier's work \cite{Homeier05} relates equivalence 

  relations, abstraction and representation functions:

  \begin{definition}[Quotient Types]

  Given a relation $R$, an abstraction function $Abs$

  and a representation function $Rep$, the predicate @{term "Quotient R Abs Rep"}

  means

  \begin{enumerate}

  \item @{thm (rhs1) Quotient_def[of "R", no_vars]}

  \item @{thm (rhs2) Quotient_def[of "R", no_vars]}

  \item @{thm (rhs3) Quotient_def[of "R", no_vars]}

  \end{enumerate}

  \end{definition}

  \noindent

  The value of this definition lies in the fact that validity of @{text "Quotient R Abs Rep"} can 

  often be proved in terms of the validity of @{text "Quotient"} over the constituent 

  types of @{text "R"}, @{text Abs} and @{text Rep}. 

  For example Homeier proves the following property for higher-order quotient

  types:

  \begin{proposition}\label{funquot}

  @{thm[mode=IfThen] fun_quotient[where ?R1.0="R\<^isub>1" and ?R2.0="R\<^isub>2" 

      and ?abs1.0="Abs\<^isub>1" and ?abs2.0="Abs\<^isub>2" and ?rep1.0="Rep\<^isub>1" and ?rep2.0="Rep\<^isub>2"]}

  \end{proposition}

  \noindent

  As a result, Homeier is able to build an automatic prover that can nearly

  always discharge a proof obligation involving @{text "Quotient"}. Our quotient

  package makes heavy 

  use of this part of Homeier's work including an extension 

  for dealing with compositions of equivalence relations defined as follows:

  \begin{definition}[Composition of Relations]

  @{abbrev "rel_conj R\<^isub>1 R\<^isub>2"} where @{text "\<circ>\<circ>"} is the predicate

  composition defined by 

  @{thm (concl) pred_compI[of "R\<^isub>1" "x" "y" "R\<^isub>2" "z"]}

  holds if and only if there exists a @{text y} such that @{thm (prem 1) pred_compI[of "R\<^isub>1" "x" "y" "R\<^isub>2" "z"]} and

  @{thm (prem 2) pred_compI[of "R\<^isub>1" "x" "y" "R\<^isub>2" "z"]}.

  \end{definition}

  \noindent

  Unfortunately, there are two predicaments with compositions of relations.

  First, a general quotient theorem for @{text "\<circ>\<circ>\<circ>"}, like the one for @{text "\<singlearr>"} 

  given in Proposition \ref{funquot},

  cannot be stated inside HOL, because of restrictions on types.

  Second, even if we were able to state such a quotient theorem, it

  would not be true in general. However, we can prove specific instances of a

  quotient theorem for composing particular quotient relations.

  For example, to lift theorems involving @{term flat} the quotient theorem for 

  composing @{text "\<approx>\<^bsub>list\<^esub>"} will be necessary: given @{term "Quotient R Abs Rep"} 

  with @{text R} being an equivalence relation, then

  @{text [display, indent=2] "Quotient (rel_list R \<circ>\<circ>\<circ> \<approx>\<^bsub>list\<^esub>) (Abs_fset \<circ> map_list Abs) (map_list Rep \<circ> Rep_fset)"}

  \vspace{-.5mm}

*}

section {* Quotient Types and Quotient Definitions\label{sec:type} *}

text {*

  The first step in a quotient construction is to take a name for the new

  type, say @{text "\<kappa>\<^isub>q"}, and an equivalence relation, say @{text R},

  defined over a raw type, say @{text "\<sigma>"}. The type of the equivalence

  relation must be @{text "\<sigma> \<Rightarrow> \<sigma> \<Rightarrow> bool"}. The user-visible part of

  the quotient type declaration is therefore

  \begin{isabelle}\ \ \ \ \ \ \ \ \ \ %%%

  \isacommand{quotient\_type}~~@{text "\<alpha>s \<kappa>\<^isub>q = \<sigma> / R"}\hfill\numbered{typedecl}

  \end{isabelle}

  \noindent

  and a proof that @{text "R"} is indeed an equivalence relation. Two concrete

  examples are

  \begin{isabelle}\ \ \ \ \ \ \ \ \ \ %%%

  \begin{tabular}{@ {}l}

  \isacommand{quotient\_type}~~@{text "int = nat \<times> nat / \<approx>\<^bsub>nat \<times> nat\<^esub>"}\\

  \isacommand{quotient\_type}~~@{text "\<alpha> fset = \<alpha> list / \<approx>\<^bsub>list\<^esub>"}

  \end{tabular}

  \end{isabelle}

  \noindent

  which introduce the type of integers and of finite sets using the

  equivalence relations @{text "\<approx>\<^bsub>nat \<times> nat\<^esub>"} and @{text

  "\<approx>\<^bsub>list\<^esub>"} defined in \eqref{natpairequiv} and

  \eqref{listequiv}, respectively (the proofs about being equivalence

  relations is omitted).  Given this data, we define for declarations shown in

  \eqref{typedecl} the quotient types internally as

  \begin{isabelle}\ \ \ \ \ \ \ \ \ \ %%%

  \isacommand{typedef}~~@{text "\<alpha>s \<kappa>\<^isub>q = {c. \<exists>x. c = R x}"}

  \end{isabelle}

  \noindent

  where the right-hand side is the (non-empty) set of equivalence classes of

  @{text "R"}. The constraint in this declaration is that the type variables

  in the raw type @{text "\<sigma>"} must be included in the type variables @{text

  "\<alpha>s"} declared for @{text "\<kappa>\<^isub>q"}. HOL will then provide us with the following

  abstraction and representation functions 

  \begin{isabelle}\ \ \ \ \ \ \ \ \ \ %%%

  @{text "abs_\<kappa>\<^isub>q :: \<sigma> set \<Rightarrow> \<alpha>s \<kappa>\<^isub>q"}\hspace{10mm}@{text "rep_\<kappa>\<^isub>q :: \<alpha>s \<kappa>\<^isub>q \<Rightarrow> \<sigma> set"}

  \end{isabelle}

  \noindent 

  As can be seen from the type, they relate the new quotient type and equivalence classes of the raw

  type. However, as Homeier \cite{Homeier05} noted, it is much more convenient

  to work with the following derived abstraction and representation functions

  \begin{isabelle}\ \ \ \ \ \ \ \ \ \ %%%

  @{text "Abs_\<kappa>\<^isub>q x \<equiv> abs_\<kappa>\<^isub>q (R x)"}\hspace{10mm}@{text "Rep_\<kappa>\<^isub>q x \<equiv> \<epsilon> (rep_\<kappa>\<^isub>q x)"}