(*<*)

theory Paper

imports "../Nominal/Nominal2" 

        "~~/src/HOL/Library/LaTeXsugar"

begin

consts

  fv :: "'a \<Rightarrow> 'b"

  abs_set :: "'a \<Rightarrow> 'b \<Rightarrow> 'c"

  alpha_bn :: "'a \<Rightarrow> 'a \<Rightarrow> bool"

  abs_set2 :: "'a \<Rightarrow> perm \<Rightarrow> 'b \<Rightarrow> 'c"

  Abs_dist :: "'a \<Rightarrow> 'b \<Rightarrow> 'c" 

  Abs_print :: "'a \<Rightarrow> 'b \<Rightarrow> 'c" 

definition

 "equal \<equiv> (op =)" 

notation (latex output)

  swap ("'(_ _')" [1000, 1000] 1000) and

  fresh ("_ # _" [51, 51] 50) and

  fresh_star ("_ #\<^sup>* _" [51, 51] 50) and

  supp ("supp _" [78] 73) and

  uminus ("-_" [78] 73) and

  If  ("if _ then _ else _" 10) and

  alpha_set ("_ \<approx>\<^raw:\,\raisebox{-1pt}{\makebox[0mm][l]{$_{\textit{set}}$}}>\<^bsup>_, _, _\<^esup> _") and

  alpha_lst ("_ \<approx>\<^raw:\,\raisebox{-1pt}{\makebox[0mm][l]{$_{\textit{list}}$}}>\<^bsup>_, _, _\<^esup> _") and

  alpha_res ("_ \<approx>\<^raw:\,\raisebox{-1pt}{\makebox[0mm][l]{$_{\textit{set+}}$}}>\<^bsup>_, _, _\<^esup> _") and

  abs_set ("_ \<approx>\<^raw:{$\,_{\textit{abs\_set}}$}> _") and

  abs_set2 ("_ \<approx>\<^raw:\raisebox{-1pt}{\makebox[0mm][l]{$\,_{\textit{list}}$}}>\<^bsup>_\<^esup>  _") and

  fv ("fa'(_')" [100] 100) and

  equal ("=") and

  alpha_abs_set ("_ \<approx>\<^raw:{$\,_{\textit{abs\_set}}$}> _") and 

  Abs_set ("[_]\<^bsub>set\<^esub>._" [20, 101] 999) and

  Abs_lst ("[_]\<^bsub>list\<^esub>._") and

  Abs_dist ("[_]\<^bsub>#list\<^esub>._") and

  Abs_res ("[_]\<^bsub>set+\<^esub>._") and

  Abs_print ("_\<^bsub>set\<^esub>._") and

  Cons ("_::_" [78,77] 73) and

  supp_set ("aux _" [1000] 10) and

  alpha_bn ("_ \<approx>bn _")

consts alpha_trm ::'a

consts fa_trm :: 'a

consts alpha_trm2 ::'a

consts fa_trm2 :: 'a

consts ast :: 'a

consts ast' :: 'a

notation (latex output) 

  alpha_trm ("\<approx>\<^bsub>trm\<^esub>") and

  fa_trm ("fa\<^bsub>trm\<^esub>") and

  alpha_trm2 ("'(\<approx>\<^bsub>assn\<^esub>, \<approx>\<^bsub>trm\<^esub>')") and

  fa_trm2 ("'(fa\<^bsub>assn\<^esub>, fa\<^bsub>trm\<^esub>')") and

  ast ("'(as, t')") and

  ast' ("'(as', t\<PRIME> ')")

(*>*)

section {* Introduction *}

text {*

  So far, Nominal Isabelle provided a mechanism for constructing

  $\alpha$-equated terms, for example lambda-terms,

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

  where free and bound variables have names.  For such $\alpha$-equated terms,

  Nominal Isabelle derives automatically a reasoning infrastructure that has

  been used successfully in formalisations of an equivalence checking

  algorithm for LF \cite{UrbanCheneyBerghofer08}, Typed

  Scheme~\cite{TobinHochstadtFelleisen08}, several calculi for concurrency

  \cite{BengtsonParow09} and a strong normalisation result for cut-elimination

  in classical logic \cite{UrbanZhu08}. It has also been used by Pollack for

  formalisations in the locally-nameless approach to binding

  \cite{SatoPollack10}.

  However, Nominal Isabelle has fared less well in a formalisation of

  the algorithm W \cite{UrbanNipkow09}, where types and type-schemes are,

  respectively, of the form

  %

  \begin{equation}\label{tysch}

  \begin{array}{l}

  @{text "T ::= x | T \<rightarrow> T"}\hspace{9mm}

  @{text "S ::= \<forall>{x\<^isub>1,\<dots>, x\<^isub>n}. T"}

  \end{array}

  \end{equation}

  %

  \noindent

  and the @{text "\<forall>"}-quantification binds a finite (possibly empty) set of

  type-variables.  While it is possible to implement this kind of more general

  binders by iterating single binders, this leads to a rather clumsy

  formalisation of W. 

  The need of iterating single binders is also one reason

  why Nominal Isabelle 

   and similar theorem provers that only provide

  mechanisms for binding single variables 

  has not fared extremely well with the

  more advanced tasks in the POPLmark challenge \cite{challenge05}, because

  also there one would like to bind multiple variables at once. 

  Binding multiple variables has interesting properties that cannot be captured

  easily by iterating single binders. For example in the case of type-schemes we do not

  want to make a distinction about the order of the bound variables. Therefore

  we would like to regard the first pair of type-schemes as $\alpha$-equivalent,

  but assuming that @{text x}, @{text y} and @{text z} are distinct variables,

  the second pair should \emph{not} be $\alpha$-equivalent:

  %

  \begin{equation}\label{ex1}

  @{text "\<forall>{x, y}. x \<rightarrow> y  \<approx>\<^isub>\<alpha>  \<forall>{y, x}. y \<rightarrow> x"}\hspace{10mm}

  @{text "\<forall>{x, y}. x \<rightarrow> y  \<notapprox>\<^isub>\<alpha>  \<forall>{z}. z \<rightarrow> z"}

  \end{equation}

  %

  \noindent

  Moreover, we like to regard type-schemes as $\alpha$-equivalent, if they differ

  only on \emph{vacuous} binders, such as

  %

  \begin{equation}\label{ex3}

  @{text "\<forall>{x}. x \<rightarrow> y  \<approx>\<^isub>\<alpha>  \<forall>{x, z}. x \<rightarrow> y"}

  \end{equation}

  %

  \noindent

  where @{text z} does not occur freely in the type.  In this paper we will

  give a general binding mechanism and associated notion of $\alpha$-equivalence

  that can be used to faithfully represent this kind of binding in Nominal

  Isabelle.  

  The difficulty of finding the right notion for $\alpha$-equivalence

  can be appreciated in this case by considering that the definition given by

  Leroy in \cite{Leroy92} is incorrect (it omits a side-condition). 

  However, the notion of $\alpha$-equivalence that is preserved by vacuous

  binders is not always wanted. For example in terms like

  %

  \begin{equation}\label{one}

  @{text "\<LET> x = 3 \<AND> y = 2 \<IN> x - y \<END>"}

  \end{equation}

  \noindent

  we might not care in which order the assignments @{text "x = 3"} and

  \mbox{@{text "y = 2"}} are given, but it would be often unusual to regard

  \eqref{one} as $\alpha$-equivalent with

  %

  \begin{center}

  @{text "\<LET> x = 3 \<AND> y = 2 \<AND> z = foo \<IN> x - y \<END>"}

  \end{center}

  %

  \noindent

  Therefore we will also provide a separate binding mechanism for cases in

  which the order of binders does not matter, but the ``cardinality'' of the

  binders has to agree.

  However, we found that this is still not sufficient for dealing with

  language constructs frequently occurring in programming language

  research. For example in @{text "\<LET>"}s containing patterns like

  %

  \begin{equation}\label{two}

  @{text "\<LET> (x, y) = (3, 2) \<IN> x - y \<END>"}

  \end{equation}

  %

  \noindent

  we want to bind all variables from the pattern inside the body of the

  $\mathtt{let}$, but we also care about the order of these variables, since

  we do not want to regard \eqref{two} as $\alpha$-equivalent with

  %

  \begin{center}

  @{text "\<LET> (y, x) = (3, 2) \<IN> x - y \<END>"}

  \end{center}

  %

  \noindent

  As a result, we provide three general binding mechanisms each of which binds

  multiple variables at once, and let the user chose which one is intended

  in a formalisation.

  %%when formalising a term-calculus.

  By providing these general binding mechanisms, however, we have to work

  around a problem that has been pointed out by Pottier \cite{Pottier06} and

  Cheney \cite{Cheney05}: in @{text "\<LET>"}-constructs of the form

  %

  \begin{center}

  @{text "\<LET> x\<^isub>1 = t\<^isub>1 \<AND> \<dots> \<AND> x\<^isub>n = t\<^isub>n \<IN> s \<END>"}

  \end{center}

  %

  \noindent

  we care about the 

  information that there are as many bound variables @{text

  "x\<^isub>i"} as there are @{text "t\<^isub>i"}. We lose this information if

  we represent the @{text "\<LET>"}-constructor by something like

  %

  \begin{center}

  @{text "\<LET> (\<lambda>x\<^isub>1\<dots>x\<^isub>n . s)  [t\<^isub>1,\<dots>,t\<^isub>n]"}

  \end{center}

  %

  \noindent

  where the notation @{text "\<lambda>_ . _"} indicates that the list of @{text

  "x\<^isub>i"} becomes bound in @{text s}. In this representation the term

  \mbox{@{text "\<LET> (\<lambda>x . s)  [t\<^isub>1, t\<^isub>2]"}} is a perfectly legal

  instance, but the lengths of the two lists do not agree. To exclude such

  terms, additional predicates about well-formed terms are needed in order to

  ensure that the two lists are of equal length. This can result in very messy

  reasoning (see for example~\cite{BengtsonParow09}). To avoid this, we will

  allow type specifications for @{text "\<LET>"}s as follows

  %

  \begin{center}

  \begin{tabular}{r@ {\hspace{2mm}}r@ {\hspace{2mm}}cl}

  @{text trm} & @{text "::="}  & @{text "\<dots>"} 

              & @{text "|"}  @{text "\<LET>  as::assn  s::trm"}\hspace{2mm} 

                                 \isacommand{bind} @{text "bn(as)"} \isacommand{in} @{text "s"}\\%%%[1mm]

  @{text assn} & @{text "::="} & @{text "\<ANIL>"}

               &  @{text "|"}  @{text "\<ACONS>  name  trm  assn"}

  \end{tabular}

  \end{center}

  %

  \noindent

  where @{text assn} is an auxiliary type representing a list of assignments

  and @{text bn} an auxiliary function identifying the variables to be bound

  by the @{text "\<LET>"}. This function can be defined by recursion over @{text

  assn} as follows

  %

  \begin{center}

  @{text "bn(\<ANIL>) ="} @{term "{}"} \hspace{5mm} 

  @{text "bn(\<ACONS> x t as) = {x} \<union> bn(as)"} 

  \end{center}

  %

  \noindent

  The scope of the binding is indicated by labels given to the types, for

  example @{text "s::trm"}, and a binding clause, in this case

  \isacommand{bind} @{text "bn(as)"} \isacommand{in} @{text "s"}. This binding

  clause states that all the names the function @{text

  "bn(as)"} returns should be bound in @{text s}.  This style of specifying terms and bindings is heavily

  inspired by the syntax of the Ott-tool \cite{ott-jfp}. 

  Though, Ott

  has only one binding mode, namely the one where the order of

  binders matters. Consequently, type-schemes with binding sets

  of names cannot be modelled in Ott.

  However, we will not be able to cope with all specifications that are

  allowed by Ott. One reason is that Ott lets the user specify ``empty'' 

  types like @{text "t ::= t t | \<lambda>x. t"}

  where no clause for variables is given. Arguably, such specifications make

  some sense in the context of Coq's type theory (which Ott supports), but not

  at all in a HOL-based environment where every datatype must have a non-empty

  set-theoretic model. % \cite{Berghofer99}.

  Another reason is that we establish the reasoning infrastructure

  for $\alpha$-\emph{equated} terms. In contrast, Ott produces  a reasoning 

  infrastructure in Isabelle/HOL for

  \emph{non}-$\alpha$-equated, or ``raw'', terms. While our $\alpha$-equated terms

  and the raw terms produced by Ott use names for bound variables,

  there is a key difference: working with $\alpha$-equated terms means, for example,  

  that the two type-schemes

  \begin{center}

  @{text "\<forall>{x}. x \<rightarrow> y  = \<forall>{x, z}. x \<rightarrow> y"} 

  \end{center}

  \noindent

  are not just $\alpha$-equal, but actually \emph{equal}! As a result, we can

  only support specifications that make sense on the level of $\alpha$-equated

  terms (offending specifications, which for example bind a variable according

  to a variable bound somewhere else, are not excluded by Ott, but we have

  to).  

  Our insistence on reasoning with $\alpha$-equated terms comes from the

  wealth of experience we gained with the older version of Nominal Isabelle:

  for non-trivial properties, reasoning with $\alpha$-equated terms is much

  easier than reasoning with raw terms. The fundamental reason for this is

  that the HOL-logic underlying Nominal Isabelle allows us to replace

  ``equals-by-equals''. In contrast, replacing

  ``$\alpha$-equals-by-$\alpha$-equals'' in a representation based on raw terms

  requires a lot of extra reasoning work.

  Although in informal settings a reasoning infrastructure for $\alpha$-equated

  terms is nearly always taken for granted, establishing it automatically in

  Isabelle/HOL is a rather non-trivial task. For every

  specification we will need to construct type(s) containing as elements the

  $\alpha$-equated terms. To do so, we use the standard HOL-technique of defining

  a new type by identifying a non-empty subset of an existing type.  The

  construction we perform in Isabelle/HOL can be illustrated by the following picture:

  %

  \begin{center}

  \begin{tikzpicture}[scale=0.89]

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

  \draw[very thick] (0.7,0.4) circle (4.25mm);

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

  \draw[rounded corners=1mm, very thick] (-1.95,0.85) rectangle (-2.85,-0.05);

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

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

  \draw ( 0.7, 0.4) node {\footnotesize\begin{tabular}{@ {}c@ {}}$\alpha$-\\[-1mm]clas.\end{tabular}};

  \draw (-2.4, 0.4) node {\footnotesize\begin{tabular}{@ {}c@ {}}$\alpha$-eq.\\[-1mm]terms\end{tabular}};

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

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

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

  \draw (-3.25, 0.55) node {\footnotesize\begin{tabular}{@ {}l@ {}}new\\[-1mm]type\end{tabular}};

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

  \draw (-0.95, 0.3) node[above=0mm] {\footnotesize{}isomorphism};

  \end{tikzpicture}

  \end{center}

  %

  \noindent

  We take as the starting point a definition of raw terms (defined as a

  datatype in Isabelle/HOL); then identify the $\alpha$-equivalence classes in

  the type of sets of raw terms according to our $\alpha$-equivalence relation,

  and finally define the new type as these $\alpha$-equivalence classes

  (non-emptiness is satisfied whenever the raw terms are definable as datatype

  in Isabelle/HOL and our relation for $\alpha$-equivalence is

  an equivalence relation).

  The fact that we obtain an isomorphism between the new type and the

  non-empty subset shows that the new type is a faithful representation of

  $\alpha$-equated terms. That is not the case for example for terms using the

  locally nameless representation of binders \cite{McKinnaPollack99}: in this

  representation there are ``junk'' terms that need to be excluded by

  reasoning about a well-formedness predicate.

  The problem with introducing a new type in Isabelle/HOL is that in order to

  be useful, a reasoning infrastructure needs to be ``lifted'' from the

  underlying subset to the new type. This is usually a tricky and arduous

  task. To ease it, we re-implemented in Isabelle/HOL \cite{KaliszykUrban11} the quotient package

  described by Homeier \cite{Homeier05} for the HOL4 system. This package

  allows us to lift definitions and theorems involving raw terms to

  definitions and theorems involving $\alpha$-equated terms. For example if we

  define the free-variable function over raw lambda-terms

  \begin{center}

  @{text "fv(x) = {x}"}\hspace{8mm}

  @{text "fv(t\<^isub>1 t\<^isub>2) = fv(t\<^isub>1) \<union> fv(t\<^isub>2)"}\hspace{8mm}

  @{text "fv(\<lambda>x.t) = fv(t) - {x}"}

  \end{center}

  \noindent

  then with the help of the quotient package we can obtain a function @{text "fv\<^sup>\<alpha>"}

  operating on quotients, or $\alpha$-equivalence classes of lambda-terms. This

  lifted function is characterised by the equations

  \begin{center}

  @{text "fv\<^sup>\<alpha>(x) = {x}"}\hspace{8mm}

  @{text "fv\<^sup>\<alpha>(t\<^isub>1 t\<^isub>2) = fv\<^sup>\<alpha>(t\<^isub>1) \<union> fv\<^sup>\<alpha>(t\<^isub>2)"}\hspace{8mm}

  @{text "fv\<^sup>\<alpha>(\<lambda>x.t) = fv\<^sup>\<alpha>(t) - {x}"}

  \end{center}

  \noindent

  (Note that this means also the term-constructors for variables, applications

  and lambda are lifted to the quotient level.)  This construction, of course,

  only works if $\alpha$-equivalence is indeed an equivalence relation, and the

  ``raw'' definitions and theorems are respectful w.r.t.~$\alpha$-equivalence.

  For example, we will not be able to lift a bound-variable function. Although

  this function can be defined for raw terms, it does not respect

  $\alpha$-equivalence and therefore cannot be lifted. 

  To sum up, every lifting

  of theorems to the quotient level needs proofs of some respectfulness

  properties (see \cite{Homeier05}). In the paper we show that we are able to

  automate these proofs and as a result can automatically establish a reasoning 

  infrastructure for $\alpha$-equated terms.\smallskip

  The examples we have in mind where our reasoning infrastructure will be

  helpful includes the term language of Core-Haskell. This term language

  involves patterns that have lists of type-, coercion- and term-variables,

  all of which are bound in @{text "\<CASE>"}-expressions. In these

  patterns we do not know in advance how many variables need to

  be bound. Another example is the specification of SML, which includes

  includes bindings as in type-schemes.\medskip

  \noindent

  {\bf Contributions:}  We provide three new definitions for when terms

  involving general binders are $\alpha$-equivalent. These definitions are

  inspired by earlier work of Pitts \cite{Pitts04}. By means of automatic

  proofs, we establish a reasoning infrastructure for $\alpha$-equated

  terms, including properties about support, freshness and equality

  conditions for $\alpha$-equated terms. We are also able to derive strong 

  induction principles that have the variable convention already built in.

  The method behind our specification of general binders is taken 

  from the Ott-tool, but we introduce crucial restrictions, and also extensions, so 

  that our specifications make sense for reasoning about $\alpha$-equated terms.  

  The main improvement over Ott is that we introduce three binding modes

  (only one is present in Ott), provide formalised definitions for $\alpha$-equivalence and 

  for free variables of our terms, and also derive a reasoning infrastructure

  for our specifications from ``first principles''.

  %\begin{figure}

  %\begin{boxedminipage}{\linewidth}

  %%\begin{center}

  %\begin{tabular}{r@ {\hspace{1mm}}r@ {\hspace{2mm}}l}

  %\multicolumn{3}{@ {}l}{Type Kinds}\\

  %@{text "\<kappa>"} & @{text "::="} & @{text "\<star> | \<kappa>\<^isub>1 \<rightarrow> \<kappa>\<^isub>2"}\smallskip\\

  %\multicolumn{3}{@ {}l}{Coercion Kinds}\\

  %@{text "\<iota>"} & @{text "::="} & @{text "\<sigma>\<^isub>1 \<sim> \<sigma>\<^isub>2"}\smallskip\\

  %\multicolumn{3}{@ {}l}{Types}\\

  %@{text "\<sigma>"} & @{text "::="} & @{text "a | T | \<sigma>\<^isub>1 \<sigma>\<^isub>2 | S\<^isub>n"}$\;\overline{@{text "\<sigma>"}}$@{text "\<^sup>n"} 

  %@{text "| \<forall>a:\<kappa>. \<sigma> | \<iota> \<Rightarrow> \<sigma>"}\smallskip\\

  %\multicolumn{3}{@ {}l}{Coercion Types}\\

  %@{text "\<gamma>"} & @{text "::="} & @{text "c | C | \<gamma>\<^isub>1 \<gamma>\<^isub>2 | S\<^isub>n"}$\;\overline{@{text "\<gamma>"}}$@{text "\<^sup>n"}

  %@{text "| \<forall>c:\<iota>. \<gamma> | \<iota> \<Rightarrow> \<gamma> "}\\

  %& @{text "|"} & @{text "refl \<sigma> | sym \<gamma> | \<gamma>\<^isub>1 \<circ> \<gamma>\<^isub>2 | \<gamma> @ \<sigma> | left \<gamma> | right \<gamma>"}\\

  %& @{text "|"} & @{text "\<gamma>\<^isub>1 \<sim> \<gamma>\<^isub>2 | rightc \<gamma> | leftc \<gamma> | \<gamma>\<^isub>1 \<triangleright> \<gamma>\<^isub>2"}\smallskip\\

  %\multicolumn{3}{@ {}l}{Terms}\\

  %@{text "e"} & @{text "::="} & @{text "x | K | \<Lambda>a:\<kappa>. e | \<Lambda>c:\<iota>. e | e \<sigma> | e \<gamma>"}\\

  %& @{text "|"} & @{text "\<lambda>x:\<sigma>. e | e\<^isub>1 e\<^isub>2 | \<LET> x:\<sigma> = e\<^isub>1 \<IN> e\<^isub>2"}\\

  %& @{text "|"} & @{text "\<CASE> e\<^isub>1 \<OF>"}$\;\overline{@{text "p \<rightarrow> e\<^isub>2"}}$ @{text "| e \<triangleright> \<gamma>"}\smallskip\\

  %\multicolumn{3}{@ {}l}{Patterns}\\

  %@{text "p"} & @{text "::="} & @{text "K"}$\;\overline{@{text "a:\<kappa>"}}\;\overline{@{text "c:\<iota>"}}\;\overline{@{text "x:\<sigma>"}}$\smallskip\\

  %\multicolumn{3}{@ {}l}{Constants}\\

  %& @{text C} & coercion constants\\

  %& @{text T} & value type constructors\\

  %& @{text "S\<^isub>n"} & n-ary type functions (which need to be fully applied)\\

  %& @{text K} & data constructors\smallskip\\

  %\multicolumn{3}{@ {}l}{Variables}\\

  %& @{text a} & type variables\\

  %& @{text c} & coercion variables\\

  %& @{text x} & term variables\\

  %\end{tabular}

  %\end{center}

  %\end{boxedminipage}

  %\caption{The System @{text "F\<^isub>C"}

  %\cite{CoreHaskell}, also often referred to as \emph{Core-Haskell}. In this

  %version of @{text "F\<^isub>C"} we made a modification by separating the

  %grammars for type kinds and coercion kinds, as well as for types and coercion

  %types. For this paper the interesting term-constructor is @{text "\<CASE>"},

  %which binds multiple type-, coercion- and term-variables.\label{corehas}}

  %\end{figure}

*}

section {* A Short Review of the Nominal Logic Work *}

text {*

  At its core, Nominal Isabelle is an adaption of the nominal logic work by

  Pitts \cite{Pitts03}. This adaptation for Isabelle/HOL is described in

  \cite{HuffmanUrban10} (including proofs). We shall briefly review this work

  to aid the description of what follows. 

  Two central notions in the nominal logic work are sorted atoms and

  sort-respecting permutations of atoms. We will use the letters @{text "a,

  b, c, \<dots>"} to stand for atoms and @{text "p, q, \<dots>"} to stand for

  permutations. The purpose of atoms is to represent variables, be they bound or free. 

  The sorts of atoms can be used to represent different kinds of

  variables, such as the term-, coercion- and type-variables in Core-Haskell.

  It is assumed that there is an infinite supply of atoms for each

  sort. In the interest of brevity, we shall restrict ourselves 

  in what follows to only one sort of atoms.

  Permutations are bijective functions from atoms to atoms that are 

  the identity everywhere except on a finite number of atoms. There is a 

  two-place permutation operation written

  @{text "_ \<bullet> _  ::  perm \<Rightarrow> \<beta> \<Rightarrow> \<beta>"}

  where the generic type @{text "\<beta>"} is the type of the object 

  over which the permutation 

  acts. In Nominal Isabelle, the identity permutation is written as @{term "0::perm"},

  the composition of two permutations @{term p} and @{term q} as \mbox{@{term "p + q"}}, 

  and the inverse permutation of @{term p} as @{text "- p"}. The permutation

  operation is defined over the type-hierarchy \cite{HuffmanUrban10};

  for example permutations acting on products, lists, sets, functions and booleans are

  given by:

  \begin{equation}\label{permute}

  \mbox{\begin{tabular}{@ {}c@ {\hspace{10mm}}c@ {}}

  \begin{tabular}{@ {}l@ {}}

  @{thm permute_prod.simps[no_vars, THEN eq_reflection]}\\[2mm]

  @{thm permute_list.simps(1)[no_vars, THEN eq_reflection]}\\

  @{thm permute_list.simps(2)[no_vars, THEN eq_reflection]}\\

  \end{tabular} &

  \begin{tabular}{@ {}l@ {}}

  @{thm permute_set_eq[no_vars, THEN eq_reflection]}\\

  @{text "p \<bullet> f \<equiv> \<lambda>x. p \<bullet> (f (- p \<bullet> x))"}\\

  @{thm permute_bool_def[no_vars, THEN eq_reflection]}

  \end{tabular}

  \end{tabular}}

  \end{equation}

  \begin{center}

  \mbox{\begin{tabular}{@ {}c@ {\hspace{4mm}}c@ {\hspace{4mm}}c@ {}}

  \begin{tabular}{@ {}l@ {}}

  @{thm permute_prod.simps[no_vars, THEN eq_reflection]}\\

  @{thm permute_bool_def[no_vars, THEN eq_reflection]}

  \end{tabular} &

  \begin{tabular}{@ {}l@ {}}

  @{thm permute_list.simps(1)[no_vars, THEN eq_reflection]}\\

  @{thm permute_list.simps(2)[no_vars, THEN eq_reflection]}\\

  \end{tabular} &

  \begin{tabular}{@ {}l@ {}}

  @{thm permute_set_eq[no_vars, THEN eq_reflection]}\\

  @{text "p \<bullet> f \<equiv> \<lambda>x. p \<bullet> (f (- p \<bullet> x))"}\\

  \end{tabular}

  \end{tabular}}

  \end{center}

  \noindent

  Concrete permutations in Nominal Isabelle are built up from swappings, 

  written as \mbox{@{text "(a b)"}}, which are permutations that behave 

  as follows:

  %

  \begin{center}

  @{text "(a b) = \<lambda>c. if a = c then b else if b = c then a else c"}

  \end{center}

  The most original aspect of the nominal logic work of Pitts is a general

  definition for the notion of the ``set of free variables of an object @{text

  "x"}''.  This notion, written @{term "supp x"}, is general in the sense that

  it applies not only to lambda-terms ($\alpha$-equated or not), but also to lists,

  products, sets and even functions. The definition depends only on the

  permutation operation and on the notion of equality defined for the type of

  @{text x}, namely:

  %

  \begin{equation}\label{suppdef}

  @{thm supp_def[no_vars, THEN eq_reflection]}

  \end{equation}

  \noindent

  There is also the derived notion for when an atom @{text a} is \emph{fresh}

  for an @{text x}, defined as @{thm fresh_def[no_vars]}.

  We use for sets of atoms the abbreviation 

  @{thm (lhs) fresh_star_def[no_vars]}, defined as 

  @{thm (rhs) fresh_star_def[no_vars]}.

  A striking consequence of these definitions is that we can prove

  without knowing anything about the structure of @{term x} that

  swapping two fresh atoms, say @{text a} and @{text b}, leaves 

  @{text x} unchanged, namely if @{text "a \<FRESH> x"} and @{text "b \<FRESH> x"}

  then @{term "(a \<rightleftharpoons> b) \<bullet> x = x"}.

  \begin{myproperty}\label{swapfreshfresh}

  @{thm[mode=IfThen] swap_fresh_fresh[no_vars]}

  \end{myproperty}

  While often the support of an object can be relatively easily 

  described, for example for atoms, products, lists, function applications, 

  booleans and permutations as follows