754
|
1 |
(*<*)
|
|
2 |
theory Paper
|
1506
|
3 |
imports "../Nominal/Test" "LaTeXsugar"
|
754
|
4 |
begin
|
1493
|
5 |
|
1657
|
6 |
consts
|
|
7 |
fv :: "'a \<Rightarrow> 'b"
|
|
8 |
abs_set :: "'a \<Rightarrow> 'b \<Rightarrow> 'c"
|
|
9 |
|
|
10 |
definition
|
|
11 |
"equal \<equiv> (op =)"
|
|
12 |
|
1493
|
13 |
notation (latex output)
|
|
14 |
swap ("'(_ _')" [1000, 1000] 1000) and
|
|
15 |
fresh ("_ # _" [51, 51] 50) and
|
1694
|
16 |
fresh_star ("_ #\<^sup>* _" [51, 51] 50) and
|
1493
|
17 |
supp ("supp _" [78] 73) and
|
|
18 |
uminus ("-_" [78] 73) and
|
1657
|
19 |
If ("if _ then _ else _" 10) and
|
1662
|
20 |
alpha_gen ("_ \<approx>\<^raw:\raisebox{-1pt}{\makebox[0mm][l]{$\,_{\textit{set}}$}}>\<^bsup>_,_,_\<^esup> _") and
|
|
21 |
alpha_lst ("_ \<approx>\<^raw:\raisebox{-1pt}{\makebox[0mm][l]{$\,_{\textit{list}}$}}>\<^bsup>_,_,_\<^esup> _") and
|
|
22 |
alpha_res ("_ \<approx>\<^raw:\raisebox{-1pt}{\makebox[0mm][l]{$\,_{\textit{res}}$}}>\<^bsup>_,_,_\<^esup> _") and
|
1657
|
23 |
abs_set ("_ \<approx>\<^raw:{$\,_{\textit{abs\_set}}$}> _") and
|
|
24 |
fv ("fv'(_')" [100] 100) and
|
|
25 |
equal ("=") and
|
|
26 |
alpha_abs ("_ \<approx>\<^raw:{$\,_{\textit{abs\_set}}$}> _") and
|
|
27 |
Abs ("[_]\<^raw:$\!$>\<^bsub>set\<^esub>._") and
|
|
28 |
Abs_lst ("[_]\<^raw:$\!$>\<^bsub>list\<^esub>._") and
|
1690
|
29 |
Abs_res ("[_]\<^raw:$\!$>\<^bsub>res\<^esub>._") and
|
|
30 |
Cons ("_::_" [78,77] 73)
|
754
|
31 |
(*>*)
|
|
32 |
|
1657
|
33 |
|
754
|
34 |
section {* Introduction *}
|
|
35 |
|
|
36 |
text {*
|
1524
|
37 |
So far, Nominal Isabelle provides a mechanism for constructing
|
1607
|
38 |
alpha-equated terms, for example
|
1485
|
39 |
|
1520
|
40 |
\begin{center}
|
1657
|
41 |
@{text "t ::= x | t t | \<lambda>x. t"}
|
1520
|
42 |
\end{center}
|
|
43 |
|
|
44 |
\noindent
|
1687
|
45 |
where free and bound variables have names. For such alpha-equated terms, Nominal Isabelle
|
1657
|
46 |
derives automatically a reasoning infrastructure that has been used
|
1550
|
47 |
successfully in formalisations of an equivalence checking algorithm for LF
|
|
48 |
\cite{UrbanCheneyBerghofer08}, Typed
|
1520
|
49 |
Scheme~\cite{TobinHochstadtFelleisen08}, several calculi for concurrency
|
1694
|
50 |
\cite{BengtsonParow09} and a strong normalisation result
|
1520
|
51 |
for cut-elimination in classical logic \cite{UrbanZhu08}. It has also been
|
|
52 |
used by Pollack for formalisations in the locally-nameless approach to
|
|
53 |
binding \cite{SatoPollack10}.
|
|
54 |
|
1535
|
55 |
However, Nominal Isabelle has fared less well in a formalisation of
|
1690
|
56 |
the algorithm W \cite{UrbanNipkow09}, where types and type-schemes are,
|
|
57 |
respectively, of the form
|
1570
|
58 |
%
|
|
59 |
\begin{equation}\label{tysch}
|
|
60 |
\begin{array}{l}
|
1657
|
61 |
@{text "T ::= x | T \<rightarrow> T"}\hspace{5mm}
|
|
62 |
@{text "S ::= \<forall>{x\<^isub>1,\<dots>, x\<^isub>n}. T"}
|
1570
|
63 |
\end{array}
|
|
64 |
\end{equation}
|
1520
|
65 |
|
|
66 |
\noindent
|
1566
|
67 |
and the quantification $\forall$ binds a finite (possibly empty) set of
|
1550
|
68 |
type-variables. While it is possible to implement this kind of more general
|
|
69 |
binders by iterating single binders, this leads to a rather clumsy
|
|
70 |
formalisation of W. The need of iterating single binders is also one reason
|
|
71 |
why Nominal Isabelle and similar theorem provers that only provide
|
|
72 |
mechanisms for binding single variables have not fared extremely well with the
|
|
73 |
more advanced tasks in the POPLmark challenge \cite{challenge05}, because
|
|
74 |
also there one would like to bind multiple variables at once.
|
1520
|
75 |
|
1577
|
76 |
Binding multiple variables has interesting properties that cannot be captured
|
1587
|
77 |
easily by iterating single binders. For example in case of type-schemes we do not
|
|
78 |
want to make a distinction about the order of the bound variables. Therefore
|
1550
|
79 |
we would like to regard the following two type-schemes as alpha-equivalent
|
1572
|
80 |
%
|
|
81 |
\begin{equation}\label{ex1}
|
1667
|
82 |
@{text "\<forall>{x, y}. x \<rightarrow> y \<approx>\<^isub>\<alpha> \<forall>{y, x}. y \<rightarrow> x"}
|
1572
|
83 |
\end{equation}
|
1520
|
84 |
|
|
85 |
\noindent
|
1657
|
86 |
but assuming that @{text x}, @{text y} and @{text z} are distinct variables,
|
1587
|
87 |
the following two should \emph{not} be alpha-equivalent
|
1572
|
88 |
%
|
|
89 |
\begin{equation}\label{ex2}
|
1667
|
90 |
@{text "\<forall>{x, y}. x \<rightarrow> y \<notapprox>\<^isub>\<alpha> \<forall>{z}. z \<rightarrow> z"}
|
1572
|
91 |
\end{equation}
|
1520
|
92 |
|
|
93 |
\noindent
|
1657
|
94 |
Moreover, we like to regard type-schemes as alpha-equivalent, if they differ
|
|
95 |
only on \emph{vacuous} binders, such as
|
1572
|
96 |
%
|
|
97 |
\begin{equation}\label{ex3}
|
1667
|
98 |
@{text "\<forall>{x}. x \<rightarrow> y \<approx>\<^isub>\<alpha> \<forall>{x, z}. x \<rightarrow> y"}
|
1572
|
99 |
\end{equation}
|
1485
|
100 |
|
1520
|
101 |
\noindent
|
1657
|
102 |
where @{text z} does not occur freely in the type. In this paper we will
|
|
103 |
give a general binding mechanism and associated notion of alpha-equivalence
|
|
104 |
that can be used to faithfully represent this kind of binding in Nominal
|
|
105 |
Isabelle. The difficulty of finding the right notion for alpha-equivalence
|
|
106 |
can be appreciated in this case by considering that the definition given by
|
|
107 |
Leroy in \cite{Leroy92} is incorrect (it omits a side-condition).
|
1524
|
108 |
|
1657
|
109 |
However, the notion of alpha-equivalence that is preserved by vacuous
|
|
110 |
binders is not always wanted. For example in terms like
|
1587
|
111 |
%
|
1535
|
112 |
\begin{equation}\label{one}
|
1657
|
113 |
@{text "\<LET> x = 3 \<AND> y = 2 \<IN> x - y \<END>"}
|
1535
|
114 |
\end{equation}
|
1520
|
115 |
|
|
116 |
\noindent
|
1524
|
117 |
we might not care in which order the assignments $x = 3$ and $y = 2$ are
|
1535
|
118 |
given, but it would be unusual to regard \eqref{one} as alpha-equivalent
|
1524
|
119 |
with
|
1587
|
120 |
%
|
1520
|
121 |
\begin{center}
|
1657
|
122 |
@{text "\<LET> x = 3 \<AND> y = 2 \<AND> z = loop \<IN> x - y \<END>"}
|
1520
|
123 |
\end{center}
|
|
124 |
|
|
125 |
\noindent
|
1550
|
126 |
Therefore we will also provide a separate binding mechanism for cases in
|
|
127 |
which the order of binders does not matter, but the ``cardinality'' of the
|
1535
|
128 |
binders has to agree.
|
1520
|
129 |
|
1550
|
130 |
However, we found that this is still not sufficient for dealing with
|
|
131 |
language constructs frequently occurring in programming language
|
1690
|
132 |
research. For example in @{text "\<LET>"}s containing patterns like
|
1587
|
133 |
%
|
1535
|
134 |
\begin{equation}\label{two}
|
1657
|
135 |
@{text "\<LET> (x, y) = (3, 2) \<IN> x - y \<END>"}
|
1535
|
136 |
\end{equation}
|
1520
|
137 |
|
|
138 |
\noindent
|
1535
|
139 |
we want to bind all variables from the pattern inside the body of the
|
|
140 |
$\mathtt{let}$, but we also care about the order of these variables, since
|
1566
|
141 |
we do not want to regard \eqref{two} as alpha-equivalent with
|
1587
|
142 |
%
|
1520
|
143 |
\begin{center}
|
1657
|
144 |
@{text "\<LET> (y, x) = (3, 2) \<IN> x - y \<END>"}
|
1520
|
145 |
\end{center}
|
|
146 |
|
|
147 |
\noindent
|
1657
|
148 |
As a result, we provide three general binding mechanisms each of which binds
|
|
149 |
multiple variables at once, and let the user chose which one is intended
|
|
150 |
when formalising a programming language calculus.
|
1485
|
151 |
|
1657
|
152 |
By providing these general binding mechanisms, however, we have to work
|
|
153 |
around a problem that has been pointed out by Pottier \cite{Pottier06} and
|
|
154 |
Cheney \cite{Cheney05}: in @{text "\<LET>"}-constructs of the form
|
1587
|
155 |
%
|
1520
|
156 |
\begin{center}
|
1657
|
157 |
@{text "\<LET> x\<^isub>1 = t\<^isub>1 \<AND> \<dots> \<AND> x\<^isub>n = t\<^isub>n \<IN> s \<END>"}
|
1520
|
158 |
\end{center}
|
|
159 |
|
|
160 |
\noindent
|
1657
|
161 |
which bind all the @{text "x\<^isub>i"} in @{text s}, we might not care
|
|
162 |
about the order in which the @{text "x\<^isub>i = t\<^isub>i"} are given,
|
|
163 |
but we do care about the information that there are as many @{text
|
|
164 |
"x\<^isub>i"} as there are @{text "t\<^isub>i"}. We lose this information if
|
|
165 |
we represent the @{text "\<LET>"}-constructor by something like
|
1587
|
166 |
%
|
1523
|
167 |
\begin{center}
|
1657
|
168 |
@{text "\<LET> [x\<^isub>1,\<dots>,x\<^isub>n].s [t\<^isub>1,\<dots>,t\<^isub>n]"}
|
1523
|
169 |
\end{center}
|
1520
|
170 |
|
1523
|
171 |
\noindent
|
1657
|
172 |
where the notation @{text "[_]._"} indicates that the @{text "x\<^isub>i"}
|
|
173 |
become bound in @{text s}. In this representation the term
|
1690
|
174 |
\mbox{@{text "\<LET> [x].s [t\<^isub>1, t\<^isub>2]"}} is a perfectly legal
|
1687
|
175 |
instance, but the lengths of two lists do not agree. To exclude such terms,
|
|
176 |
additional predicates about well-formed
|
1657
|
177 |
terms are needed in order to ensure that the two lists are of equal
|
|
178 |
length. This can result into very messy reasoning (see for
|
|
179 |
example~\cite{BengtsonParow09}). To avoid this, we will allow type
|
|
180 |
specifications for $\mathtt{let}$s as follows
|
1587
|
181 |
%
|
1528
|
182 |
\begin{center}
|
|
183 |
\begin{tabular}{r@ {\hspace{2mm}}r@ {\hspace{2mm}}l}
|
1657
|
184 |
@{text trm} & @{text "::="} & @{text "\<dots>"}\\
|
|
185 |
& @{text "|"} & @{text "\<LET> a::assn s::trm"}\hspace{4mm}
|
|
186 |
\isacommand{bind} @{text "bn(a)"} \isacommand{in} @{text "s"}\\[1mm]
|
|
187 |
@{text assn} & @{text "::="} & @{text "\<ANIL>"}\\
|
|
188 |
& @{text "|"} & @{text "\<ACONS> name trm assn"}
|
1528
|
189 |
\end{tabular}
|
|
190 |
\end{center}
|
|
191 |
|
|
192 |
\noindent
|
1657
|
193 |
where @{text assn} is an auxiliary type representing a list of assignments
|
|
194 |
and @{text bn} an auxiliary function identifying the variables to be bound
|
1687
|
195 |
by the @{text "\<LET>"}. This function can be defined by recursion over @{text
|
1657
|
196 |
assn} as follows
|
1528
|
197 |
|
|
198 |
\begin{center}
|
1657
|
199 |
@{text "bn(\<ANIL>) ="} @{term "{}"} \hspace{5mm}
|
|
200 |
@{text "bn(\<ACONS> x t as) = {x} \<union> bn(as)"}
|
1528
|
201 |
\end{center}
|
1523
|
202 |
|
1528
|
203 |
\noindent
|
1550
|
204 |
The scope of the binding is indicated by labels given to the types, for
|
1657
|
205 |
example @{text "s::trm"}, and a binding clause, in this case
|
|
206 |
\isacommand{bind} @{text "bn(a)"} \isacommand{in} @{text "s"}, that states
|
|
207 |
to bind in @{text s} all the names the function call @{text "bn(a)"} returns.
|
|
208 |
This style of specifying terms and bindings is heavily inspired by the
|
|
209 |
syntax of the Ott-tool \cite{ott-jfp}.
|
|
210 |
|
1528
|
211 |
|
1545
|
212 |
However, we will not be able to deal with all specifications that are
|
1617
|
213 |
allowed by Ott. One reason is that Ott lets the user to specify ``empty''
|
|
214 |
types like
|
1570
|
215 |
|
|
216 |
\begin{center}
|
1657
|
217 |
@{text "t ::= t t | \<lambda>x. t"}
|
1570
|
218 |
\end{center}
|
|
219 |
|
|
220 |
\noindent
|
1617
|
221 |
where no clause for variables is given. Arguably, such specifications make
|
|
222 |
some sense in the context of Coq's type theory (which Ott supports), but not
|
|
223 |
at all in a HOL-based environment where every datatype must have a non-empty
|
|
224 |
set-theoretic model.
|
1570
|
225 |
|
|
226 |
Another reason is that we establish the reasoning infrastructure
|
|
227 |
for alpha-\emph{equated} terms. In contrast, Ott produces a reasoning
|
|
228 |
infrastructure in Isabelle/HOL for
|
1545
|
229 |
\emph{non}-alpha-equated, or ``raw'', terms. While our alpha-equated terms
|
1556
|
230 |
and the raw terms produced by Ott use names for bound variables,
|
1690
|
231 |
there is a key difference: working with alpha-equated terms means, for example,
|
1693
|
232 |
that the two type-schemes
|
1528
|
233 |
|
|
234 |
\begin{center}
|
1667
|
235 |
@{text "\<forall>{x}. x \<rightarrow> y = \<forall>{x, z}. x \<rightarrow> y"}
|
1528
|
236 |
\end{center}
|
|
237 |
|
|
238 |
\noindent
|
1657
|
239 |
are not just alpha-equal, but actually \emph{equal}. As a result, we can
|
|
240 |
only support specifications that make sense on the level of alpha-equated
|
|
241 |
terms (offending specifications, which for example bind a variable according
|
|
242 |
to a variable bound somewhere else, are not excluded by Ott, but we have
|
1687
|
243 |
to).
|
|
244 |
|
|
245 |
Our insistence on reasoning with alpha-equated terms comes from the
|
1657
|
246 |
wealth of experience we gained with the older version of Nominal Isabelle:
|
|
247 |
for non-trivial properties, reasoning about alpha-equated terms is much
|
|
248 |
easier than reasoning with raw terms. The fundamental reason for this is
|
|
249 |
that the HOL-logic underlying Nominal Isabelle allows us to replace
|
|
250 |
``equals-by-equals''. In contrast, replacing
|
|
251 |
``alpha-equals-by-alpha-equals'' in a representation based on raw terms
|
|
252 |
requires a lot of extra reasoning work.
|
1535
|
253 |
|
1657
|
254 |
Although in informal settings a reasoning infrastructure for alpha-equated
|
|
255 |
terms is nearly always taken for granted, establishing it automatically in
|
|
256 |
the Isabelle/HOL theorem prover is a rather non-trivial task. For every
|
|
257 |
specification we will need to construct a type containing as elements the
|
|
258 |
alpha-equated terms. To do so, we use the standard HOL-technique of defining
|
|
259 |
a new type by identifying a non-empty subset of an existing type. The
|
1667
|
260 |
construction we perform in Isabelle/HOL can be illustrated by the following picture:
|
1657
|
261 |
|
1528
|
262 |
\begin{center}
|
1552
|
263 |
\begin{tikzpicture}
|
|
264 |
%\draw[step=2mm] (-4,-1) grid (4,1);
|
|
265 |
|
|
266 |
\draw[very thick] (0.7,0.4) circle (4.25mm);
|
|
267 |
\draw[rounded corners=1mm, very thick] ( 0.0,-0.8) rectangle ( 1.8, 0.9);
|
|
268 |
\draw[rounded corners=1mm, very thick] (-1.95,0.85) rectangle (-2.85,-0.05);
|
|
269 |
|
|
270 |
\draw (-2.0, 0.845) -- (0.7,0.845);
|
|
271 |
\draw (-2.0,-0.045) -- (0.7,-0.045);
|
|
272 |
|
|
273 |
\draw ( 0.7, 0.4) node {\begin{tabular}{@ {}c@ {}}$\alpha$-\\[-1mm]clas.\end{tabular}};
|
|
274 |
\draw (-2.4, 0.4) node {\begin{tabular}{@ {}c@ {}}$\alpha$-eq.\\[-1mm]terms\end{tabular}};
|
|
275 |
\draw (1.8, 0.48) node[right=-0.1mm]
|
|
276 |
{\begin{tabular}{@ {}l@ {}}existing\\[-1mm] type\\ (sets of raw terms)\end{tabular}};
|
|
277 |
\draw (0.9, -0.35) node {\begin{tabular}{@ {}l@ {}}non-empty\\[-1mm]subset\end{tabular}};
|
|
278 |
\draw (-3.25, 0.55) node {\begin{tabular}{@ {}l@ {}}new\\[-1mm]type\end{tabular}};
|
|
279 |
|
|
280 |
\draw[<->, very thick] (-1.8, 0.3) -- (-0.1,0.3);
|
|
281 |
\draw (-0.95, 0.3) node[above=0mm] {isomorphism};
|
|
282 |
|
|
283 |
\end{tikzpicture}
|
1528
|
284 |
\end{center}
|
|
285 |
|
|
286 |
\noindent
|
1657
|
287 |
We take as the starting point a definition of raw terms (defined as a
|
|
288 |
datatype in Isabelle/HOL); identify then the alpha-equivalence classes in
|
|
289 |
the type of sets of raw terms according to our alpha-equivalence relation
|
|
290 |
and finally define the new type as these alpha-equivalence classes
|
|
291 |
(non-emptiness is satisfied whenever the raw terms are definable as datatype
|
1690
|
292 |
in Isabelle/HOL and the property that our relation for alpha-equivalence is
|
1657
|
293 |
indeed an equivalence relation).
|
1556
|
294 |
|
1657
|
295 |
The fact that we obtain an isomorphism between the new type and the
|
|
296 |
non-empty subset shows that the new type is a faithful representation of
|
|
297 |
alpha-equated terms. That is not the case for example for terms using the
|
|
298 |
locally nameless representation of binders \cite{McKinnaPollack99}: in this
|
|
299 |
representation there are ``junk'' terms that need to be excluded by
|
|
300 |
reasoning about a well-formedness predicate.
|
1556
|
301 |
|
1657
|
302 |
The problem with introducing a new type in Isabelle/HOL is that in order to
|
|
303 |
be useful, a reasoning infrastructure needs to be ``lifted'' from the
|
|
304 |
underlying subset to the new type. This is usually a tricky and arduous
|
|
305 |
task. To ease it, we re-implemented in Isabelle/HOL the quotient package
|
|
306 |
described by Homeier \cite{Homeier05} for the HOL4 system. This package
|
|
307 |
allows us to lift definitions and theorems involving raw terms to
|
|
308 |
definitions and theorems involving alpha-equated terms. For example if we
|
|
309 |
define the free-variable function over raw lambda-terms
|
1577
|
310 |
|
|
311 |
\begin{center}
|
1657
|
312 |
@{text "fv(x) = {x}"}\hspace{10mm}
|
|
313 |
@{text "fv(t\<^isub>1 t\<^isub>2) = fv(t\<^isub>1) \<union> fv(t\<^isub>2)"}\\[1mm]
|
|
314 |
@{text "fv(\<lambda>x.t) = fv(t) - {x}"}
|
1577
|
315 |
\end{center}
|
|
316 |
|
|
317 |
\noindent
|
1690
|
318 |
then with the help of the quotient package we obtain a function @{text "fv\<^sup>\<alpha>"}
|
1617
|
319 |
operating on quotients, or alpha-equivalence classes of lambda-terms. This
|
1628
|
320 |
lifted function is characterised by the equations
|
1577
|
321 |
|
|
322 |
\begin{center}
|
1657
|
323 |
@{text "fv\<^sup>\<alpha>(x) = {x}"}\hspace{10mm}
|
|
324 |
@{text "fv\<^sup>\<alpha>(t\<^isub>1 t\<^isub>2) = fv\<^sup>\<alpha>(t\<^isub>1) \<union> fv\<^sup>\<alpha>(t\<^isub>2)"}\\[1mm]
|
|
325 |
@{text "fv\<^sup>\<alpha>(\<lambda>x.t) = fv\<^sup>\<alpha>(t) - {x}"}
|
1577
|
326 |
\end{center}
|
|
327 |
|
|
328 |
\noindent
|
|
329 |
(Note that this means also the term-constructors for variables, applications
|
|
330 |
and lambda are lifted to the quotient level.) This construction, of course,
|
1694
|
331 |
only works if alpha-equivalence is indeed an equivalence relation, and the
|
|
332 |
lifted definitions and theorems are respectful w.r.t.~alpha-equivalence.
|
|
333 |
For example, we will not be able to lift a bound-variable function. Although
|
|
334 |
this function can be defined for raw terms, it does not respect
|
|
335 |
alpha-equivalence and therefore cannot be lifted. To sum up, every lifting
|
|
336 |
of theorems to the quotient level needs proofs of some respectfulness
|
|
337 |
properties (see \cite{Homeier05}). In the paper we show that we are able to
|
|
338 |
automate these proofs and therefore can establish a reasoning infrastructure
|
|
339 |
for alpha-equated terms.
|
1667
|
340 |
|
|
341 |
The examples we have in mind where our reasoning infrastructure will be
|
1694
|
342 |
helpful includes the term language of System @{text "F\<^isub>C"}, also
|
|
343 |
known as Core-Haskell (see Figure~\ref{corehas}). This term language
|
|
344 |
involves patterns that have lists of type- and term-variables (the
|
|
345 |
arguments of constructors) all of which are bound in case expressions. One
|
|
346 |
difficulty is that each of these variables come with a kind or type
|
|
347 |
annotation. Representing such binders with single binders and reasoning
|
|
348 |
about them in a theorem prover would be a major pain. \medskip
|
1506
|
349 |
|
1528
|
350 |
\noindent
|
|
351 |
{\bf Contributions:} We provide new definitions for when terms
|
|
352 |
involving multiple binders are alpha-equivalent. These definitions are
|
1607
|
353 |
inspired by earlier work of Pitts \cite{Pitts04}. By means of automatic
|
1528
|
354 |
proofs, we establish a reasoning infrastructure for alpha-equated
|
|
355 |
terms, including properties about support, freshness and equality
|
1607
|
356 |
conditions for alpha-equated terms. We are also able to derive, at the moment
|
|
357 |
only manually, strong induction principles that
|
|
358 |
have the variable convention already built in.
|
1667
|
359 |
|
|
360 |
\begin{figure}
|
1687
|
361 |
\begin{boxedminipage}{\linewidth}
|
|
362 |
\begin{center}
|
1699
|
363 |
\begin{tabular}{r@ {\hspace{1mm}}r@ {\hspace{2mm}}l}
|
1690
|
364 |
\multicolumn{3}{@ {}l}{Type Kinds}\\
|
1699
|
365 |
@{text "\<kappa>"} & @{text "::="} & @{text "\<star> | \<kappa>\<^isub>1 \<rightarrow> \<kappa>\<^isub>2"}\smallskip\\
|
1690
|
366 |
\multicolumn{3}{@ {}l}{Coercion Kinds}\\
|
1699
|
367 |
@{text "\<iota>"} & @{text "::="} & @{text "\<sigma>\<^isub>1 \<sim> \<sigma>\<^isub>2"}\smallskip\\
|
1690
|
368 |
\multicolumn{3}{@ {}l}{Types}\\
|
1694
|
369 |
@{text "\<sigma>"} & @{text "::="} & @{text "a | T | \<sigma>\<^isub>1 \<sigma>\<^isub>2 | S\<^isub>n"}$\;\overline{@{text "\<sigma>"}}$@{text "\<^sup>n"}
|
1699
|
370 |
@{text "| \<forall>a:\<kappa>. \<sigma> | \<iota> \<Rightarrow> \<sigma>"}\smallskip\\
|
1690
|
371 |
\multicolumn{3}{@ {}l}{Coercion Types}\\
|
1694
|
372 |
@{text "\<gamma>"} & @{text "::="} & @{text "c | C | \<gamma>\<^isub>1 \<gamma>\<^isub>2 | S\<^isub>n"}$\;\overline{@{text "\<gamma>"}}$@{text "\<^sup>n"}
|
1699
|
373 |
@{text "| \<forall>c:\<iota>. \<gamma> | \<iota> \<Rightarrow> \<gamma> "}\\
|
|
374 |
& @{text "|"} & @{text "refl \<sigma> | sym \<gamma> | \<gamma>\<^isub>1 \<circ> \<gamma>\<^isub>2 | \<gamma> @ \<sigma> | left \<gamma> | right \<gamma>"}\\
|
|
375 |
& @{text "|"} & @{text "\<gamma>\<^isub>1 \<sim> \<gamma>\<^isub>2 | rightc \<gamma> | leftc \<gamma> | \<gamma>\<^isub>1 \<triangleright> \<gamma>\<^isub>2"}\smallskip\\
|
1690
|
376 |
\multicolumn{3}{@ {}l}{Terms}\\
|
1699
|
377 |
@{text "e"} & @{text "::="} & @{text "x | K | \<Lambda>a:\<kappa>. e | \<Lambda>c:\<iota>. e | e \<sigma> | e \<gamma>"}\\
|
|
378 |
& @{text "|"} & @{text "\<lambda>x:\<sigma>. e | e\<^isub>1 e\<^isub>2 | \<LET> x:\<sigma> = e\<^isub>1 \<IN> e\<^isub>2"}\\
|
|
379 |
& @{text "|"} & @{text "\<CASE> e\<^isub>1 \<OF>"}$\;\overline{@{text "p \<rightarrow> e\<^isub>2"}}$ @{text "| e \<triangleright> \<gamma>"}\smallskip\\
|
1690
|
380 |
\multicolumn{3}{@ {}l}{Patterns}\\
|
1699
|
381 |
@{text "p"} & @{text "::="} & @{text "K"}$\;\overline{@{text "a:\<kappa>"}}\;\overline{@{text "c:\<iota>"}}\;\overline{@{text "x:\<sigma>"}}$\smallskip\\
|
1690
|
382 |
\multicolumn{3}{@ {}l}{Constants}\\
|
1699
|
383 |
& @{text C} & coercion constants\\
|
|
384 |
& @{text T} & value type constructors\\
|
|
385 |
& @{text "S\<^isub>n"} & n-ary type functions (which need to be fully applied)\\
|
|
386 |
& @{text K} & data constructors\smallskip\\
|
1690
|
387 |
\multicolumn{3}{@ {}l}{Variables}\\
|
1699
|
388 |
& @{text a} & type variables\\
|
|
389 |
& @{text c} & coercion variables\\
|
|
390 |
& @{text x} & term variables\\
|
1687
|
391 |
\end{tabular}
|
|
392 |
\end{center}
|
|
393 |
\end{boxedminipage}
|
1699
|
394 |
\caption{The term-language of System @{text "F\<^isub>C"}
|
|
395 |
\cite{CoreHaskell}, also often referred to as \emph{Core-Haskell}. In this
|
|
396 |
version of the term-language we made a modification by separating the
|
1702
|
397 |
grammars for type and coercion kinds, as well as for types and coercion
|
|
398 |
types. For this paper the interesting term-constructor is @{text "\<CASE>"},
|
|
399 |
which binds multiple type-, coercion- and term-variables.\label{corehas}}
|
1667
|
400 |
\end{figure}
|
1485
|
401 |
*}
|
|
402 |
|
1493
|
403 |
section {* A Short Review of the Nominal Logic Work *}
|
|
404 |
|
|
405 |
text {*
|
1556
|
406 |
At its core, Nominal Isabelle is an adaption of the nominal logic work by
|
|
407 |
Pitts \cite{Pitts03}. This adaptation for Isabelle/HOL is described in
|
1694
|
408 |
\cite{HuffmanUrban10} (including proofs). We shall briefly review this work
|
|
409 |
to aid the description of what follows.
|
|
410 |
|
|
411 |
Two central notions in the nominal
|
|
412 |
logic work are sorted atoms and sort-respecting permutations of atoms. The
|
|
413 |
sorts can be used to represent different kinds of variables, such as the
|
|
414 |
term- and type-variables in Core-Haskell, and it is assumed that there is an
|
|
415 |
infinite supply of atoms for each sort. However, in order to simplify the
|
|
416 |
description, we shall assume in what follows that there is only one sort of
|
|
417 |
atoms.
|
1493
|
418 |
|
|
419 |
Permutations are bijective functions from atoms to atoms that are
|
|
420 |
the identity everywhere except on a finite number of atoms. There is a
|
|
421 |
two-place permutation operation written
|
1617
|
422 |
%
|
|
423 |
@{text[display,indent=5] "_ \<bullet> _ :: perm \<Rightarrow> \<beta> \<Rightarrow> \<beta>"}
|
1493
|
424 |
|
|
425 |
\noindent
|
1628
|
426 |
in which the generic type @{text "\<beta>"} stands for the type of the object
|
1694
|
427 |
over which the permutation
|
1617
|
428 |
acts. In Nominal Isabelle, the identity permutation is written as @{term "0::perm"},
|
1690
|
429 |
the composition of two permutations @{term p} and @{term q} as \mbox{@{term "p + q"}},
|
1570
|
430 |
and the inverse permutation of @{term p} as @{text "- p"}. The permutation
|
1694
|
431 |
operation is defined by induction over the type-hierarchy, for example as follows
|
|
432 |
for products, lists, sets, functions and booleans (see \cite{HuffmanUrban10}):
|
1702
|
433 |
%
|
1694
|
434 |
\begin{equation}
|
|
435 |
\mbox{\begin{tabular}{@ {}cc@ {}}
|
1690
|
436 |
\begin{tabular}{@ {}l@ {}}
|
|
437 |
@{thm permute_prod.simps[no_vars, THEN eq_reflection]}\\[2mm]
|
|
438 |
@{thm permute_list.simps(1)[no_vars, THEN eq_reflection]}\\
|
|
439 |
@{thm permute_list.simps(2)[no_vars, THEN eq_reflection]}\\
|
|
440 |
\end{tabular} &
|
|
441 |
\begin{tabular}{@ {}l@ {}}
|
|
442 |
@{thm permute_set_eq[no_vars, THEN eq_reflection]}\\
|
1694
|
443 |
@{text "p \<bullet> f \<equiv> \<lambda>x. p \<bullet> (f (- p \<bullet> x))"}\\
|
1690
|
444 |
@{thm permute_bool_def[no_vars, THEN eq_reflection]}\\
|
|
445 |
\end{tabular}
|
1694
|
446 |
\end{tabular}}
|
|
447 |
\end{equation}
|
1690
|
448 |
|
|
449 |
\noindent
|
1694
|
450 |
Concrete permutations are build up from swappings, written as @{text "(a
|
|
451 |
b)"}, which are permutations that behave as follows:
|
1617
|
452 |
%
|
|
453 |
@{text[display,indent=5] "(a b) = \<lambda>c. if a = c then b else if b = c then a else c"}
|
|
454 |
|
1570
|
455 |
The most original aspect of the nominal logic work of Pitts is a general
|
|
456 |
definition for the notion of ``the set of free variables of an object @{text
|
|
457 |
"x"}''. This notion, written @{term "supp x"}, is general in the sense that
|
1628
|
458 |
it applies not only to lambda-terms (alpha-equated or not), but also to lists,
|
1570
|
459 |
products, sets and even functions. The definition depends only on the
|
|
460 |
permutation operation and on the notion of equality defined for the type of
|
|
461 |
@{text x}, namely:
|
1617
|
462 |
%
|
1506
|
463 |
@{thm[display,indent=5] supp_def[no_vars, THEN eq_reflection]}
|
1493
|
464 |
|
|
465 |
\noindent
|
|
466 |
There is also the derived notion for when an atom @{text a} is \emph{fresh}
|
|
467 |
for an @{text x}, defined as
|
1617
|
468 |
%
|
1506
|
469 |
@{thm[display,indent=5] fresh_def[no_vars]}
|
1493
|
470 |
|
|
471 |
\noindent
|
1517
62d6f7acc110
corrected the strong induction principle in the lambda-calculus case; gave a second (oartial) version that is more elegant
Christian Urban <urbanc@in.tum.de>
diff
changeset
|
472 |
We also use for sets of atoms the abbreviation
|
62d6f7acc110
corrected the strong induction principle in the lambda-calculus case; gave a second (oartial) version that is more elegant
Christian Urban <urbanc@in.tum.de>
diff
changeset
|
473 |
@{thm (lhs) fresh_star_def[no_vars]} defined as
|
62d6f7acc110
corrected the strong induction principle in the lambda-calculus case; gave a second (oartial) version that is more elegant
Christian Urban <urbanc@in.tum.de>
diff
changeset
|
474 |
@{thm (rhs) fresh_star_def[no_vars]}.
|
1493
|
475 |
A striking consequence of these definitions is that we can prove
|
|
476 |
without knowing anything about the structure of @{term x} that
|
|
477 |
swapping two fresh atoms, say @{text a} and @{text b}, leave
|
1506
|
478 |
@{text x} unchanged.
|
|
479 |
|
1517
62d6f7acc110
corrected the strong induction principle in the lambda-calculus case; gave a second (oartial) version that is more elegant
Christian Urban <urbanc@in.tum.de>
diff
changeset
|
480 |
\begin{property}
|
1506
|
481 |
@{thm[mode=IfThen] swap_fresh_fresh[no_vars]}
|
1517
62d6f7acc110
corrected the strong induction principle in the lambda-calculus case; gave a second (oartial) version that is more elegant
Christian Urban <urbanc@in.tum.de>
diff
changeset
|
482 |
\end{property}
|
1506
|
483 |
|
1517
62d6f7acc110
corrected the strong induction principle in the lambda-calculus case; gave a second (oartial) version that is more elegant
Christian Urban <urbanc@in.tum.de>
diff
changeset
|
484 |
\noindent
|
1690
|
485 |
While it is often clear what the support for a construction is, for
|
|
486 |
example
|
|
487 |
%
|
|
488 |
\begin{eqnarray}
|
|
489 |
@{term "supp (x, y)"} & = & @{term "supp x \<union> supp y"}\\
|
|
490 |
@{term "supp []"} & = & @{term "{}"}\\
|
|
491 |
@{term "supp (x#xs)"} & = & @{term "supp (x, xs)"}\\
|
|
492 |
@{text "supp (f x)"} & @{text "\<subseteq>"} & @{term "supp (f, x)"}\\
|
|
493 |
@{term "supp b"} & = & @{term "{}"}
|
|
494 |
\end{eqnarray}
|
|
495 |
|
|
496 |
\noindent
|
|
497 |
it can sometimes be difficult to establish the support precisely,
|
1694
|
498 |
and only give an approximation (see functions above). Such approximations can
|
|
499 |
be formalised with the notion \emph{supports}, defined as follows.
|
1693
|
500 |
|
|
501 |
\begin{defn}
|
|
502 |
A set @{text S} \emph{supports} @{text x} if for all atoms @{text a} and @{text b}
|
|
503 |
not in @{text S} we have @{term "(a \<rightleftharpoons> b) \<bullet> x = x"}.
|
|
504 |
\end{defn}
|
1690
|
505 |
|
1693
|
506 |
\noindent
|
1694
|
507 |
The point of this definition is that we can show:
|
1693
|
508 |
|
|
509 |
\begin{property}
|
|
510 |
{\it i)} @{thm[mode=IfThen] supp_is_subset[no_vars]}
|
|
511 |
{\it ii)} @{thm supp_supports[no_vars]}.
|
|
512 |
\end{property}
|
|
513 |
|
|
514 |
\noindent
|
|
515 |
Another important notion in the nominal logic work is \emph{equivariance}.
|
1694
|
516 |
For a function @{text f}, lets say of type @{text "\<alpha> \<Rightarrow> \<beta>"}, to be equivariant
|
|
517 |
means that every permutation leaves @{text f} unchanged, or equivalently that
|
|
518 |
a permutation applied to an application @{text "f x"} can be moved to its
|
|
519 |
arguments. That is
|
|
520 |
|
|
521 |
\begin{center}
|
|
522 |
@{text "\<forall>p. p \<bullet> f = f"} \hspace{5mm}
|
|
523 |
@{text "\<forall>p. p \<bullet> (f x) = f (p \<bullet> x)"}
|
|
524 |
\end{center}
|
|
525 |
|
|
526 |
\noindent
|
|
527 |
From the first equation we can be easily deduce that an equivariant function has
|
|
528 |
empty support.
|
1517
62d6f7acc110
corrected the strong induction principle in the lambda-calculus case; gave a second (oartial) version that is more elegant
Christian Urban <urbanc@in.tum.de>
diff
changeset
|
529 |
|
1662
|
530 |
%\begin{property}
|
|
531 |
%@{thm[mode=IfThen] at_set_avoiding[no_vars]}
|
|
532 |
%\end{property}
|
1493
|
533 |
|
|
534 |
*}
|
|
535 |
|
1485
|
536 |
|
1620
|
537 |
section {* General Binders\label{sec:binders} *}
|
1485
|
538 |
|
1517
62d6f7acc110
corrected the strong induction principle in the lambda-calculus case; gave a second (oartial) version that is more elegant
Christian Urban <urbanc@in.tum.de>
diff
changeset
|
539 |
text {*
|
1587
|
540 |
In Nominal Isabelle, the user is expected to write down a specification of a
|
|
541 |
term-calculus and then a reasoning infrastructure is automatically derived
|
1617
|
542 |
from this specification (remember that Nominal Isabelle is a definitional
|
1587
|
543 |
extension of Isabelle/HOL, which does not introduce any new axioms).
|
1579
|
544 |
|
1657
|
545 |
In order to keep our work with deriving the reasoning infrastructure
|
|
546 |
manageable, we will wherever possible state definitions and perform proofs
|
|
547 |
on the user-level of Isabelle/HOL, as opposed to write custom ML-code that
|
|
548 |
generates them anew for each specification. To that end, we will consider
|
|
549 |
first pairs @{text "(as, x)"} of type @{text "(atom set) \<times> \<beta>"}. These pairs
|
|
550 |
are intended to represent the abstraction, or binding, of the set @{text
|
|
551 |
"as"} in the body @{text "x"}.
|
1570
|
552 |
|
1657
|
553 |
The first question we have to answer is when the pairs @{text "(as, x)"} and
|
|
554 |
@{text "(bs, y)"} are alpha-equivalent? (At the moment we are interested in
|
|
555 |
the notion of alpha-equivalence that is \emph{not} preserved by adding
|
|
556 |
vacuous binders.) To answer this, we identify four conditions: {\it i)}
|
|
557 |
given a free-variable function @{text "fv"} of type \mbox{@{text "\<beta> \<Rightarrow> atom
|
|
558 |
set"}}, then @{text x} and @{text y} need to have the same set of free
|
|
559 |
variables; moreover there must be a permutation @{text p} such that {\it
|
1687
|
560 |
ii)} @{text p} leaves the free variables of @{text x} and @{text y} unchanged, but
|
1657
|
561 |
{\it iii)} ``moves'' their bound names so that we obtain modulo a relation,
|
1662
|
562 |
say \mbox{@{text "_ R _"}}, two equivalent terms. We also require {\it iv)} that
|
|
563 |
@{text p} makes the sets of abstracted atoms @{text as} and @{text bs} equal. The
|
1657
|
564 |
requirements {\it i)} to {\it iv)} can be stated formally as follows:
|
1556
|
565 |
%
|
1572
|
566 |
\begin{equation}\label{alphaset}
|
|
567 |
\begin{array}{@ {\hspace{10mm}}r@ {\hspace{2mm}}l}
|
1687
|
568 |
\multicolumn{2}{l}{@{term "(as, x) \<approx>gen R fv p (bs, y)"}\hspace{2mm}@{text "\<equiv>"}\hspace{30mm}}\\[1mm]
|
1657
|
569 |
& @{term "fv(x) - as = fv(y) - bs"}\\
|
|
570 |
@{text "\<and>"} & @{term "(fv(x) - as) \<sharp>* p"}\\
|
|
571 |
@{text "\<and>"} & @{text "(p \<bullet> x) R y"}\\
|
|
572 |
@{text "\<and>"} & @{term "(p \<bullet> as) = bs"}\\
|
1572
|
573 |
\end{array}
|
1556
|
574 |
\end{equation}
|
|
575 |
|
|
576 |
\noindent
|
1657
|
577 |
Note that this relation is dependent on the permutation @{text
|
|
578 |
"p"}. Alpha-equivalence between two pairs is then the relation where we
|
|
579 |
existentially quantify over this @{text "p"}. Also note that the relation is
|
|
580 |
dependent on a free-variable function @{text "fv"} and a relation @{text
|
|
581 |
"R"}. The reason for this extra generality is that we will use
|
|
582 |
$\approx_{\textit{set}}$ for both ``raw'' terms and alpha-equated terms. In
|
|
583 |
the latter case, $R$ will be replaced by equality @{text "="} and for raw terms we
|
|
584 |
will prove that @{text "fv"} is equal to the support of @{text
|
|
585 |
x} and @{text y}.
|
1572
|
586 |
|
|
587 |
The definition in \eqref{alphaset} does not make any distinction between the
|
1579
|
588 |
order of abstracted variables. If we want this, then we can define alpha-equivalence
|
|
589 |
for pairs of the form \mbox{@{text "(as, x)"}} with type @{text "(atom list) \<times> \<beta>"}
|
|
590 |
as follows
|
1572
|
591 |
%
|
|
592 |
\begin{equation}\label{alphalist}
|
|
593 |
\begin{array}{@ {\hspace{10mm}}r@ {\hspace{2mm}}l}
|
1687
|
594 |
\multicolumn{2}{l}{@{term "(as, x) \<approx>lst R fv p (bs, y)"}\hspace{2mm}@{text "\<equiv>"}\hspace{30mm}}\\[1mm]
|
1657
|
595 |
& @{term "fv(x) - (set as) = fv(y) - (set bs)"}\\
|
|
596 |
\wedge & @{term "(fv(x) - set as) \<sharp>* p"}\\
|
1572
|
597 |
\wedge & @{text "(p \<bullet> x) R y"}\\
|
1657
|
598 |
\wedge & @{term "(p \<bullet> as) = bs"}\\
|
1572
|
599 |
\end{array}
|
|
600 |
\end{equation}
|
|
601 |
|
|
602 |
\noindent
|
1657
|
603 |
where @{term set} is a function that coerces a list of atoms into a set of atoms.
|
|
604 |
Now the last clause ensures that the order of the binders matters.
|
1556
|
605 |
|
1657
|
606 |
If we do not want to make any difference between the order of binders \emph{and}
|
1579
|
607 |
also allow vacuous binders, then we keep sets of binders, but drop the fourth
|
|
608 |
condition in \eqref{alphaset}:
|
1572
|
609 |
%
|
1579
|
610 |
\begin{equation}\label{alphares}
|
1572
|
611 |
\begin{array}{@ {\hspace{10mm}}r@ {\hspace{2mm}}l}
|
1687
|
612 |
\multicolumn{2}{l}{@{term "(as, x) \<approx>res R fv p (bs, y)"}\hspace{2mm}@{text "\<equiv>"}\hspace{30mm}}\\[1mm]
|
1657
|
613 |
& @{term "fv(x) - as = fv(y) - bs"}\\
|
|
614 |
\wedge & @{term "(fv(x) - as) \<sharp>* p"}\\
|
1572
|
615 |
\wedge & @{text "(p \<bullet> x) R y"}\\
|
|
616 |
\end{array}
|
|
617 |
\end{equation}
|
1556
|
618 |
|
1662
|
619 |
It might be useful to consider some examples for how these definitions of alpha-equivalence
|
|
620 |
pan out in practise.
|
1579
|
621 |
For this consider the case of abstracting a set of variables over types (as in type-schemes).
|
1657
|
622 |
We set @{text R} to be the equality and for @{text "fv(T)"} we define
|
1572
|
623 |
|
|
624 |
\begin{center}
|
1657
|
625 |
@{text "fv(x) = {x}"} \hspace{5mm} @{text "fv(T\<^isub>1 \<rightarrow> T\<^isub>2) = fv(T\<^isub>1) \<union> fv(T\<^isub>2)"}
|
1572
|
626 |
\end{center}
|
|
627 |
|
|
628 |
\noindent
|
1657
|
629 |
Now recall the examples shown in \eqref{ex1}, \eqref{ex2} and
|
1687
|
630 |
\eqref{ex3}. It can be easily checked that @{text "({x, y}, x \<rightarrow> y)"} and
|
|
631 |
@{text "({y, x}, y \<rightarrow> x)"} are equal according to $\approx_{\textit{set}}$ and
|
1657
|
632 |
$\approx_{\textit{res}}$ by taking @{text p} to be the swapping @{term "(x \<rightleftharpoons>
|
|
633 |
y)"}. In case of @{text "x \<noteq> y"}, then @{text "([x, y], x \<rightarrow> y)"}
|
1687
|
634 |
$\not\approx_{\textit{list}}$ @{text "([y, x], x \<rightarrow> y)"} since there is no permutation
|
1657
|
635 |
that makes the lists @{text "[x, y]"} and @{text "[y, x]"} equal, and also
|
|
636 |
leaves the type \mbox{@{text "x \<rightarrow> y"}} unchanged. Another example is
|
1687
|
637 |
@{text "({x}, x)"} $\approx_{\textit{res}}$ @{text "({x, y}, x)"} which holds by
|
1657
|
638 |
taking @{text p} to be the
|
|
639 |
identity permutation. However, if @{text "x \<noteq> y"}, then @{text "({x}, x)"}
|
1687
|
640 |
$\not\approx_{\textit{set}}$ @{text "({x, y}, x)"} since there is no permutation
|
1657
|
641 |
that makes the
|
1687
|
642 |
sets @{text "{x}"} and @{text "{x, y}"} equal (similarly for $\approx_{\textit{list}}$).
|
|
643 |
It can also relatively easily be shown that all tree notions of alpha-equivalence
|
|
644 |
coincide, if we only abstract a single atom.
|
1579
|
645 |
|
1657
|
646 |
% looks too ugly
|
|
647 |
%\noindent
|
|
648 |
%Let $\star$ range over $\{set, res, list\}$. We prove next under which
|
|
649 |
%conditions the $\approx\hspace{0.05mm}_\star^{\fv, R, p}$ are equivalence
|
|
650 |
%relations and equivariant:
|
|
651 |
%
|
|
652 |
%\begin{lemma}
|
|
653 |
%{\it i)} Given the fact that $x\;R\;x$ holds, then
|
|
654 |
%$(as, x) \approx\hspace{0.05mm}^{\fv, R, 0}_\star (as, x)$. {\it ii)} Given
|
|
655 |
%that @{text "(p \<bullet> x) R y"} implies @{text "(-p \<bullet> y) R x"}, then
|
|
656 |
%$(as, x) \approx\hspace{0.05mm}^{\fv, R, p}_\star (bs, y)$ implies
|
|
657 |
%$(bs, y) \approx\hspace{0.05mm}^{\fv, R, - p}_\star (as, x)$. {\it iii)} Given
|
|
658 |
%that @{text "(p \<bullet> x) R y"} and @{text "(q \<bullet> y) R z"} implies
|
|
659 |
%@{text "((q + p) \<bullet> x) R z"}, then $(as, x) \approx\hspace{0.05mm}^{\fv, R, p}_\star (bs, y)$
|
|
660 |
%and $(bs, y) \approx\hspace{0.05mm}^{\fv, R, q}_\star (cs, z)$ implies
|
|
661 |
%$(as, x) \approx\hspace{0.05mm}^{\fv, R, q + p}_\star (cs, z)$. Given
|
|
662 |
%@{text "(q \<bullet> x) R y"} implies @{text "(p \<bullet> (q \<bullet> x)) R (p \<bullet> y)"} and
|
|
663 |
%@{text "p \<bullet> (fv x) = fv (p \<bullet> x)"} then @{text "p \<bullet> (fv y) = fv (p \<bullet> y)"}, then
|
|
664 |
%$(as, x) \approx\hspace{0.05mm}^{\fv, R, q}_\star (bs, y)$ implies
|
|
665 |
%$(p \;\isasymbullet\; as, p \;\isasymbullet\; x) \approx\hspace{0.05mm}^{\fv, R, q}_\star
|
|
666 |
%(p \;\isasymbullet\; bs, p \;\isasymbullet\; y)$.
|
|
667 |
%\end{lemma}
|
|
668 |
|
|
669 |
%\begin{proof}
|
|
670 |
%All properties are by unfolding the definitions and simple calculations.
|
|
671 |
%\end{proof}
|
|
672 |
|
|
673 |
|
1687
|
674 |
In the rest of this section we are going to introduce a type- and term-constructors
|
|
675 |
for abstraction. For this we define
|
1657
|
676 |
%
|
|
677 |
\begin{equation}
|
|
678 |
@{term "abs_set (as, x) (bs, x) \<equiv> \<exists>p. alpha_gen (as, x) equal supp p (bs, x)"}
|
|
679 |
\end{equation}
|
|
680 |
|
1579
|
681 |
\noindent
|
1687
|
682 |
(similarly for $\approx_{\textit{abs\_list}}$
|
|
683 |
and $\approx_{\textit{abs\_res}}$). We can show that these relations are equivalence
|
|
684 |
relations and equivariant.
|
1579
|
685 |
|
1687
|
686 |
\begin{lemma}\label{alphaeq} The relations
|
|
687 |
$\approx_{\textit{abs\_set}}$,
|
|
688 |
$\approx_{\textit{abs\_list}}$
|
|
689 |
and $\approx_{\textit{abs\_res}}$
|
|
690 |
are equivalence
|
1662
|
691 |
relations, and if @{term "abs_set (as, x) (bs, y)"} then also
|
1687
|
692 |
@{term "abs_set (p \<bullet> as, p \<bullet> x) (p \<bullet> bs, p \<bullet> y)"} (similarly for
|
|
693 |
the other two relations).
|
1657
|
694 |
\end{lemma}
|
|
695 |
|
|
696 |
\begin{proof}
|
|
697 |
Reflexivity is by taking @{text "p"} to be @{text "0"}. For symmetry we have
|
|
698 |
a permutation @{text p} and for the proof obligation take @{term "-p"}. In case
|
1662
|
699 |
of transitivity, we have two permutations @{text p} and @{text q}, and for the
|
|
700 |
proof obligation use @{text "q + p"}. All conditions are then by simple
|
1657
|
701 |
calculations.
|
|
702 |
\end{proof}
|
|
703 |
|
|
704 |
\noindent
|
1687
|
705 |
This lemma allows us to use our quotient package and introduce
|
1662
|
706 |
new types @{text "\<beta> abs_set"}, @{text "\<beta> abs_res"} and @{text "\<beta> abs_list"}
|
1687
|
707 |
representing alpha-equivalence classes of pairs. The elements in these types
|
1657
|
708 |
we will, respectively, write as:
|
|
709 |
|
|
710 |
\begin{center}
|
|
711 |
@{term "Abs as x"} \hspace{5mm}
|
|
712 |
@{term "Abs_lst as x"} \hspace{5mm}
|
|
713 |
@{term "Abs_res as x"}
|
|
714 |
\end{center}
|
|
715 |
|
1662
|
716 |
\noindent
|
1687
|
717 |
indicating that a set or list is abstracted in @{text x}. We will call the types
|
|
718 |
\emph{abstraction types} and their elements \emph{abstractions}. The important
|
|
719 |
property we need is a characterisation for the support of abstractions, namely
|
1662
|
720 |
|
1687
|
721 |
\begin{thm}[Support of Abstractions]\label{suppabs}
|
|
722 |
Assuming @{text x} has finite support, then
|
1662
|
723 |
\begin{center}
|
1687
|
724 |
\begin{tabular}{l@ {\hspace{2mm}}c@ {\hspace{2mm}}l}
|
|
725 |
@{thm (lhs) supp_abs(1)[no_vars]} & $=$ & @{thm (rhs) supp_abs(1)[no_vars]}\\
|
|
726 |
@{thm (lhs) supp_abs(2)[no_vars]} & $=$ & @{thm (rhs) supp_abs(2)[no_vars]}\\
|
|
727 |
@{thm (lhs) supp_abs(3)[no_vars]} & $=$ & @{thm (rhs) supp_abs(3)[no_vars]}
|
|
728 |
\end{tabular}
|
1662
|
729 |
\end{center}
|
1687
|
730 |
\end{thm}
|
1662
|
731 |
|
|
732 |
\noindent
|
1687
|
733 |
We will only show in the rest of the section the first equation, as the others
|
|
734 |
follow similar arguments. By definition of the abstraction type @{text "abs_set"}
|
|
735 |
we have
|
|
736 |
%
|
|
737 |
\begin{equation}\label{abseqiff}
|
|
738 |
@{thm (lhs) abs_eq_iff(1)[where bs="as" and cs="bs", no_vars]} \;\text{if and only if}\;
|
|
739 |
@{thm (rhs) abs_eq_iff(1)[where bs="as" and cs="bs", no_vars]}
|
|
740 |
\end{equation}
|
|
741 |
|
|
742 |
\noindent
|
|
743 |
With this, we can show the following lemma about swapping two atoms (the permutation
|
|
744 |
operation for abstractions is the one lifted for pairs).\footnote{metion this in the nominal
|
|
745 |
logic section}
|
1662
|
746 |
|
|
747 |
\begin{lemma}
|
|
748 |
@{thm[mode=IfThen] abs_swap1(1)[no_vars]}
|
|
749 |
\end{lemma}
|
|
750 |
|
|
751 |
\begin{proof}
|
1687
|
752 |
By using \eqref{abseqiff}, this lemma is straightforward when observing that
|
|
753 |
the assumptions give us
|
1662
|
754 |
@{term "(a \<rightleftharpoons> b) \<bullet> (supp x - bs) = (supp x - bs)"} and that @{text supp}
|
1687
|
755 |
and set difference are equivariant.
|
1662
|
756 |
\end{proof}
|
1587
|
757 |
|
1687
|
758 |
\noindent
|
|
759 |
This lemma gives us
|
|
760 |
%
|
|
761 |
\begin{equation}\label{halfone}
|
|
762 |
@{thm abs_supports(1)[no_vars]}
|
|
763 |
\end{equation}
|
|
764 |
|
|
765 |
\noindent
|
|
766 |
which with \ref{} gives us one half of Thm~\ref{suppabs}. The other half is
|
|
767 |
a bit more involved. We first define an auxiliary function
|
|
768 |
%
|
|
769 |
\begin{center}
|
|
770 |
@{thm supp_res.simps[THEN eq_reflection, no_vars]}
|
|
771 |
\end{center}
|
|
772 |
|
|
773 |
|
1587
|
774 |
\begin{lemma}
|
|
775 |
$supp ([as]set. x) = supp x - as$
|
|
776 |
\end{lemma}
|
1687
|
777 |
|
|
778 |
\noindent
|
|
779 |
The point of these general lemmas about pairs is that we can define and prove properties
|
1693
|
780 |
about them conveniently on the Isabelle level, and in addition can use them in what
|
1687
|
781 |
follows next when we have to deal with specific instances of term-specification.
|
1517
62d6f7acc110
corrected the strong induction principle in the lambda-calculus case; gave a second (oartial) version that is more elegant
Christian Urban <urbanc@in.tum.de>
diff
changeset
|
782 |
*}
|
62d6f7acc110
corrected the strong induction principle in the lambda-calculus case; gave a second (oartial) version that is more elegant
Christian Urban <urbanc@in.tum.de>
diff
changeset
|
783 |
|
1491
|
784 |
section {* Alpha-Equivalence and Free Variables *}
|
|
785 |
|
1520
|
786 |
text {*
|
1637
|
787 |
Our specifications for term-calculi are heavily inspired by the existing
|
|
788 |
datatype package of Isabelle/HOL and by the syntax of the Ott-tool
|
|
789 |
\cite{ott-jfp}. A specification is a collection of (possibly mutual
|
|
790 |
recursive) type declarations, say @{text "ty"}$^\alpha_1$, \ldots,
|
|
791 |
@{text ty}$^\alpha_n$, and an associated collection
|
|
792 |
of binding functions, say @{text bn}$^\alpha_1$, \ldots, @{text
|
|
793 |
bn}$^\alpha_m$. The syntax in Nominal Isabelle for such specifications is
|
1693
|
794 |
roughly as follows:
|
1628
|
795 |
%
|
1619
|
796 |
\begin{equation}\label{scheme}
|
1636
|
797 |
\mbox{\begin{tabular}{@ {\hspace{-5mm}}p{1.8cm}l}
|
1617
|
798 |
type \mbox{declaration part} &
|
1611
|
799 |
$\begin{cases}
|
|
800 |
\mbox{\begin{tabular}{l}
|
1637
|
801 |
\isacommand{nominal\_datatype} @{text ty}$^\alpha_1 = \ldots$\\
|
|
802 |
\isacommand{and} @{text ty}$^\alpha_2 = \ldots$\\
|
1587
|
803 |
$\ldots$\\
|
1637
|
804 |
\isacommand{and} @{text ty}$^\alpha_n = \ldots$\\
|
1611
|
805 |
\end{tabular}}
|
|
806 |
\end{cases}$\\
|
1617
|
807 |
binding \mbox{function part} &
|
1611
|
808 |
$\begin{cases}
|
|
809 |
\mbox{\begin{tabular}{l}
|
1637
|
810 |
\isacommand{with} @{text bn}$^\alpha_1$ \isacommand{and} \ldots \isacommand{and} @{text bn}$^\alpha_m$\\
|
1611
|
811 |
\isacommand{where}\\
|
1587
|
812 |
$\ldots$\\
|
1611
|
813 |
\end{tabular}}
|
|
814 |
\end{cases}$\\
|
1619
|
815 |
\end{tabular}}
|
|
816 |
\end{equation}
|
1587
|
817 |
|
|
818 |
\noindent
|
1637
|
819 |
Every type declaration @{text ty}$^\alpha_{1..n}$ consists of a collection of
|
1611
|
820 |
term-constructors, each of which comes with a list of labelled
|
1620
|
821 |
types that stand for the types of the arguments of the term-constructor.
|
1637
|
822 |
For example a term-constructor @{text "C\<^sup>\<alpha>"} might have
|
1611
|
823 |
|
|
824 |
\begin{center}
|
1637
|
825 |
@{text "C\<^sup>\<alpha> label\<^isub>1::ty"}$'_1$ @{text "\<dots> label\<^isub>l::ty"}$'_l\;\;$ @{text "binding_clauses"}
|
1611
|
826 |
\end{center}
|
1587
|
827 |
|
1611
|
828 |
\noindent
|
1637
|
829 |
whereby some of the @{text ty}$'_{1..l}$ (or their components) are contained in the collection
|
|
830 |
of @{text ty}$^\alpha_{1..n}$ declared in \eqref{scheme}. In this case we will call the
|
1636
|
831 |
corresponding argument a \emph{recursive argument}. The labels annotated on
|
|
832 |
the types are optional and can be used in the (possibly empty) list of
|
1637
|
833 |
\emph{binding clauses}. These clauses indicate the binders and their scope of
|
|
834 |
in a term-constructor. They come in three \emph{modes}:
|
1636
|
835 |
|
1587
|
836 |
|
1611
|
837 |
\begin{center}
|
1617
|
838 |
\begin{tabular}{l}
|
|
839 |
\isacommand{bind}\; {\it binders}\; \isacommand{in}\; {\it label}\\
|
|
840 |
\isacommand{bind\_set}\; {\it binders}\; \isacommand{in}\; {\it label}\\
|
|
841 |
\isacommand{bind\_res}\; {\it binders}\; \isacommand{in}\; {\it label}\\
|
|
842 |
\end{tabular}
|
1611
|
843 |
\end{center}
|
|
844 |
|
|
845 |
\noindent
|
1636
|
846 |
The first mode is for binding lists of atoms (the order of binders matters); the second is for sets
|
1637
|
847 |
of binders (the order does not matter, but the cardinality does) and the last is for
|
1620
|
848 |
sets of binders (with vacuous binders preserving alpha-equivalence).
|
|
849 |
|
|
850 |
In addition we distinguish between \emph{shallow} binders and \emph{deep}
|
|
851 |
binders. Shallow binders are of the form \isacommand{bind}\; {\it label}\;
|
1637
|
852 |
\isacommand{in}\; {\it label'} (similar for the other two modes). The
|
1620
|
853 |
restriction we impose on shallow binders is that the {\it label} must either
|
|
854 |
refer to a type that is an atom type or to a type that is a finite set or
|
1637
|
855 |
list of an atom type. Two examples for the use of shallow binders are the
|
|
856 |
specification of lambda-terms, where a single name is bound, and of
|
|
857 |
type-schemes, where a finite set of names is bound:
|
1611
|
858 |
|
|
859 |
\begin{center}
|
1612
|
860 |
\begin{tabular}{@ {}cc@ {}}
|
|
861 |
\begin{tabular}{@ {}l@ {\hspace{-1mm}}}
|
|
862 |
\isacommand{nominal\_datatype} {\it lam} =\\
|
|
863 |
\hspace{5mm}\phantom{$\mid$} Var\;{\it name}\\
|
|
864 |
\hspace{5mm}$\mid$ App\;{\it lam}\;{\it lam}\\
|
|
865 |
\hspace{5mm}$\mid$ Lam\;{\it x::name}\;{\it t::lam}\\
|
1617
|
866 |
\hspace{21mm}\isacommand{bind} {\it x} \isacommand{in} {\it t}\\
|
1611
|
867 |
\end{tabular} &
|
1612
|
868 |
\begin{tabular}{@ {}l@ {}}
|
|
869 |
\isacommand{nominal\_datatype} {\it ty} =\\
|
|
870 |
\hspace{5mm}\phantom{$\mid$} TVar\;{\it name}\\
|
|
871 |
\hspace{5mm}$\mid$ TFun\;{\it ty}\;{\it ty}\\
|
1617
|
872 |
\isacommand{and} {\it tsc} = All\;{\it xs::(name fset)}\;{\it T::ty}\\
|
1619
|
873 |
\hspace{24mm}\isacommand{bind\_res} {\it xs} \isacommand{in} {\it T}\\
|
1611
|
874 |
\end{tabular}
|
|
875 |
\end{tabular}
|
|
876 |
\end{center}
|
1587
|
877 |
|
1612
|
878 |
\noindent
|
1637
|
879 |
Note that in this specification \emph{name} refers to an atom type.
|
1628
|
880 |
If we have shallow binders that ``share'' a body, for instance $t$ in
|
1637
|
881 |
the following term-constructor
|
1620
|
882 |
|
|
883 |
\begin{center}
|
|
884 |
\begin{tabular}{ll}
|
1637
|
885 |
\it {\rm Foo} x::name y::name t::lam & \it
|
1620
|
886 |
\isacommand{bind}\;x\;\isacommand{in}\;t,\;
|
|
887 |
\isacommand{bind}\;y\;\isacommand{in}\;t
|
|
888 |
\end{tabular}
|
|
889 |
\end{center}
|
|
890 |
|
|
891 |
\noindent
|
1628
|
892 |
then we have to make sure the modes of the binders agree. We cannot
|
1637
|
893 |
have, for instance, in the first binding clause the mode \isacommand{bind}
|
|
894 |
and in the second \isacommand{bind\_set}.
|
1620
|
895 |
|
|
896 |
A \emph{deep} binder uses an auxiliary binding function that ``picks'' out
|
1636
|
897 |
the atoms in one argument of the term-constructor, which can be bound in
|
1628
|
898 |
other arguments and also in the same argument (we will
|
1637
|
899 |
call such binders \emph{recursive}, see below).
|
1620
|
900 |
The binding functions are expected to return either a set of atoms
|
|
901 |
(for \isacommand{bind\_set} and \isacommand{bind\_res}) or a list of atoms
|
|
902 |
(for \isacommand{bind}). They can be defined by primitive recursion over the
|
|
903 |
corresponding type; the equations must be given in the binding function part of
|
1628
|
904 |
the scheme shown in \eqref{scheme}. For example for a calculus containing lets
|
1637
|
905 |
with tuple patterns, you might specify
|
1617
|
906 |
|
1619
|
907 |
\begin{center}
|
|
908 |
\begin{tabular}{l}
|
|
909 |
\isacommand{nominal\_datatype} {\it trm} =\\
|
|
910 |
\hspace{5mm}\phantom{$\mid$} Var\;{\it name}\\
|
|
911 |
\hspace{5mm}$\mid$ App\;{\it trm}\;{\it trm}\\
|
|
912 |
\hspace{5mm}$\mid$ Lam\;{\it x::name}\;{\it t::trm}
|
|
913 |
\;\;\isacommand{bind} {\it x} \isacommand{in} {\it t}\\
|
|
914 |
\hspace{5mm}$\mid$ Let\;{\it p::pat}\;{\it trm}\; {\it t::trm}
|
1636
|
915 |
\;\;\isacommand{bind} {\it bn(p)} \isacommand{in} {\it t}\\
|
1619
|
916 |
\isacommand{and} {\it pat} =\\
|
1637
|
917 |
\hspace{5mm}\phantom{$\mid$} PNil\\
|
|
918 |
\hspace{5mm}$\mid$ PVar\;{\it name}\\
|
|
919 |
\hspace{5mm}$\mid$ PTup\;{\it pat}\;{\it pat}\\
|
1636
|
920 |
\isacommand{with} {\it bn::pat $\Rightarrow$ atom list}\\
|
1637
|
921 |
\isacommand{where} $\textit{bn}(\textrm{PNil}) = []$\\
|
|
922 |
\hspace{5mm}$\mid$ $\textit{bn}(\textrm{PVar}\;x) = [\textit{atom}\; x]$\\
|
|
923 |
\hspace{5mm}$\mid$ $\textit{bn}(\textrm{PTup}\;p_1\;p_2) = \textit{bn}(p_1)\; @\;\textit{bn}(p_2)$\\
|
1619
|
924 |
\end{tabular}
|
|
925 |
\end{center}
|
1617
|
926 |
|
1619
|
927 |
\noindent
|
1637
|
928 |
In this specification the function @{text "bn"} determines which atoms of @{text p} are
|
|
929 |
bound in the argument @{text "t"}. Note that the second last clause the function @{text "atom"}
|
|
930 |
coerces a name into the generic atom type of Nominal Isabelle. This allows
|
|
931 |
us to treat binders of different atom type uniformly.
|
|
932 |
|
|
933 |
As will shortly become clear, we cannot return an atom in a binding function
|
|
934 |
that is also bound in the corresponding term-constructor. That means in the
|
|
935 |
example above that the term-constructors PVar and PTup must not have a
|
|
936 |
binding clause. In the present version of Nominal Isabelle, we also adopted
|
|
937 |
the restriction from the Ott-tool that binding functions can only return:
|
|
938 |
the empty set or empty list (as in case PNil), a singleton set or singleton
|
|
939 |
list containing an atom (case PVar), or unions of atom sets or appended atom
|
|
940 |
lists (case PTup). This restriction will simplify proofs later on.
|
|
941 |
The the most drastic restriction we have to impose on deep binders is that
|
|
942 |
we cannot have ``overlapping'' deep binders. Consider for example the
|
|
943 |
term-constructors:
|
1617
|
944 |
|
1620
|
945 |
\begin{center}
|
|
946 |
\begin{tabular}{ll}
|
1637
|
947 |
\it {\rm Foo} p::pat q::pat t::trm & \it \isacommand{bind}\;bn(p)\;\isacommand{in}\;t,\;
|
1620
|
948 |
\isacommand{bind}\;bn(q)\;\isacommand{in}\;t\\
|
1637
|
949 |
\it {\rm Foo}$'$x::name p::pat t::trm & \it \it \isacommand{bind}\;x\;\isacommand{in}\;t,\;
|
1620
|
950 |
\isacommand{bind}\;bn(p)\;\isacommand{in}\;t
|
|
951 |
|
|
952 |
\end{tabular}
|
|
953 |
\end{center}
|
|
954 |
|
|
955 |
\noindent
|
1637
|
956 |
In the first case we bind all atoms from the pattern @{text p} in @{text t}
|
|
957 |
and also all atoms from @{text q} in @{text t}. As a result we have no way
|
|
958 |
to determine whether the binder came from the binding function @{text
|
|
959 |
"bn(p)"} or @{text "bn(q)"}. Similarly in the second case. There the binder
|
|
960 |
@{text "bn(p)"} overlaps with the shallow binder @{text x}. The reason why
|
1693
|
961 |
we must exclude such specifications is that they cannot be represent by
|
1637
|
962 |
the general binders described in Section \ref{sec:binders}. However
|
|
963 |
the following two term-constructors are allowed
|
1620
|
964 |
|
|
965 |
\begin{center}
|
|
966 |
\begin{tabular}{ll}
|
1637
|
967 |
\it {\rm Bar} p::pat t::trm s::trm & \it \isacommand{bind}\;bn(p)\;\isacommand{in}\;t,\;
|
1620
|
968 |
\isacommand{bind}\;bn(p)\;\isacommand{in}\;s\\
|
1637
|
969 |
\it {\rm Bar}$'$p::pat t::trm & \it \isacommand{bind}\;bn(p)\;\isacommand{in}\;p,\;
|
1620
|
970 |
\isacommand{bind}\;bn(p)\;\isacommand{in}\;t\\
|
|
971 |
\end{tabular}
|
|
972 |
\end{center}
|
|
973 |
|
|
974 |
\noindent
|
1628
|
975 |
since there is no overlap of binders.
|
1619
|
976 |
|
1637
|
977 |
Note that in the last example we wrote {\it\isacommand{bind}\;bn(p)\;\isacommand{in}\;p}.
|
1693
|
978 |
Whenever such a binding clause is present, we will call the binder \emph{recursive}.
|
1637
|
979 |
To see the purpose for this, consider ``plain'' Lets and Let\_recs:
|
1636
|
980 |
|
|
981 |
\begin{center}
|
1637
|
982 |
\begin{tabular}{@ {}l@ {}}
|
1636
|
983 |
\isacommand{nominal\_datatype} {\it trm} =\\
|
|
984 |
\hspace{5mm}\phantom{$\mid$}\ldots\\
|
|
985 |
\hspace{5mm}$\mid$ Let\;{\it a::assn}\; {\it t::trm}
|
|
986 |
\;\;\isacommand{bind} {\it bn(a)} \isacommand{in} {\it t}\\
|
1637
|
987 |
\hspace{5mm}$\mid$ Let\_rec\;{\it a::assn}\; {\it t::trm}
|
|
988 |
\;\;\isacommand{bind} {\it bn(a)} \isacommand{in} {\it t},
|
|
989 |
\isacommand{bind} {\it bn(a)} \isacommand{in} {\it a}\\
|
1636
|
990 |
\isacommand{and} {\it assn} =\\
|
|
991 |
\hspace{5mm}\phantom{$\mid$} ANil\\
|
|
992 |
\hspace{5mm}$\mid$ ACons\;{\it name}\;{\it trm}\;{\it assn}\\
|
|
993 |
\isacommand{with} {\it bn::assn $\Rightarrow$ atom list}\\
|
|
994 |
\isacommand{where} $bn(\textrm{ANil}) = []$\\
|
|
995 |
\hspace{5mm}$\mid$ $bn(\textrm{ACons}\;x\;t\;a) = [atom\; x]\; @\; bn(a)$\\
|
|
996 |
\end{tabular}
|
|
997 |
\end{center}
|
|
998 |
|
|
999 |
\noindent
|
1637
|
1000 |
The difference is that with Let we only want to bind the atoms @{text
|
|
1001 |
"bn(a)"} in the term @{text t}, but with Let\_rec we also want to bind the atoms
|
|
1002 |
inside the assignment. This requires recursive binders and also has
|
|
1003 |
consequences for the free variable function and alpha-equivalence relation,
|
|
1004 |
which we are going to explain in the rest of this section.
|
|
1005 |
|
|
1006 |
Having dealt with all syntax matters, the problem now is how we can turn
|
|
1007 |
specifications into actual type definitions in Isabelle/HOL and then
|
|
1008 |
establish a reasoning infrastructure for them. Because of the problem
|
|
1009 |
Pottier and Cheney pointed out, we cannot in general re-arrange arguments of
|
|
1010 |
term-constructors so that binders and their bodies are next to each other, and
|
|
1011 |
then use the type constructors @{text "abs_set"}, @{text "abs_res"} and
|
|
1012 |
@{text "abs_list"} from Section \ref{sec:binders}. Therefore we will first
|
|
1013 |
extract datatype definitions from the specification and then define an
|
1693
|
1014 |
alpha-equivalence relation over them.
|
1637
|
1015 |
|
|
1016 |
|
|
1017 |
The datatype definition can be obtained by just stripping off the
|
|
1018 |
binding clauses and the labels on the types. We also have to invent
|
|
1019 |
new names for the types @{text "ty\<^sup>\<alpha>"} and term-constructors @{text "C\<^sup>\<alpha>"}
|
|
1020 |
given by user. In our implementation we just use an affix like
|
1636
|
1021 |
|
|
1022 |
\begin{center}
|
1637
|
1023 |
@{text "ty\<^sup>\<alpha> \<mapsto> ty_raw"} \hspace{7mm} @{text "C\<^sup>\<alpha> \<mapsto> C_raw"}
|
1636
|
1024 |
\end{center}
|
|
1025 |
|
|
1026 |
\noindent
|
1637
|
1027 |
The resulting datatype definition is legal in Isabelle/HOL provided the datatypes are
|
|
1028 |
non-empty and the types in the constructors only occur in positive
|
1693
|
1029 |
position (see \cite{} for an indepth explanation of the datatype package
|
1637
|
1030 |
in Isabelle/HOL). We then define the user-specified binding
|
|
1031 |
functions by primitive recursion over the raw datatypes. We can also
|
|
1032 |
easily define a permutation operation by primitive recursion so that for each
|
|
1033 |
term constructor @{text "C_raw ty\<^isub>1 \<dots> ty\<^isub>n"} we have that
|
1587
|
1034 |
|
1628
|
1035 |
\begin{center}
|
1637
|
1036 |
@{text "p \<bullet> (C_raw x\<^isub>1 \<dots> x\<^isub>n) \<equiv> C_raw (p \<bullet> x\<^isub>1) \<dots> (p \<bullet> x\<^isub>n)"}
|
1628
|
1037 |
\end{center}
|
|
1038 |
|
|
1039 |
\noindent
|
1637
|
1040 |
From this definition we can easily show that the raw datatypes are
|
|
1041 |
all permutation types (Def ??) by a simple structural induction over
|
|
1042 |
the @{text "ty_raw"}s.
|
|
1043 |
|
1693
|
1044 |
The first non-trivial step we have to perform is the generation free-variable
|
1637
|
1045 |
functions from the specifications. Given types @{text "ty\<^isub>1, \<dots>, ty\<^isub>n"}
|
|
1046 |
we need to define the free-variable functions
|
|
1047 |
|
|
1048 |
\begin{center}
|
|
1049 |
@{text "fv_ty\<^isub>1 :: ty\<^isub>1 \<Rightarrow> atom set \<dots> fv_ty\<^isub>n :: ty\<^isub>n \<Rightarrow> atom set"}
|
|
1050 |
\end{center}
|
|
1051 |
|
|
1052 |
\noindent
|
|
1053 |
and given binding functions @{text "bn_ty\<^isub>1, \<dots>, bn_ty\<^isub>m"} we also need to define
|
|
1054 |
the free-variable functions
|
1628
|
1055 |
|
1637
|
1056 |
\begin{center}
|
|
1057 |
@{text "fv_bn_ty\<^isub>1 :: ty\<^isub>1 \<Rightarrow> atom set \<dots> fv_bn_ty\<^isub>m :: ty\<^isub>m \<Rightarrow> atom set"}
|
|
1058 |
\end{center}
|
1636
|
1059 |
|
1637
|
1060 |
\noindent
|
|
1061 |
The basic idea behind these free-variable functions is to collect all atoms
|
|
1062 |
that are not bound in a term constructor, but because of the rather
|
|
1063 |
complicated binding mechanisms the details are somewhat involved.
|
|
1064 |
|
|
1065 |
Given a term-constructor @{text "C_raw ty\<^isub>1 \<dots> ty\<^isub>n"}, of type @{text ty} together with
|
|
1066 |
some binding clauses, the function @{text "fv_ty (C_raw x\<^isub>1 \<dots> x\<^isub>n)"} will be
|
|
1067 |
the union of the values defined below for each argument, say @{text "x\<^isub>i"} with type @{text "ty\<^isub>i"}.
|
|
1068 |
From the binding clause of this term constructor, we can determine whether the
|
|
1069 |
argument @{text "x\<^isub>i"} is a shallow or deep binder, and in the latter case also
|
|
1070 |
whether it is a recursive or non-recursive of a binder. In these cases the value is:
|
1628
|
1071 |
|
|
1072 |
\begin{center}
|
1636
|
1073 |
\begin{tabular}{cp{7cm}}
|
|
1074 |
$\bullet$ & @{term "{}"} provided @{text "x\<^isub>i"} is a shallow binder\\
|
1693
|
1075 |
$\bullet$ & @{text "ft_bn_by\<^isub>i x\<^isub>i"} provided @{text "x\<^isub>i"} is a deep non-recursive binder\\
|
1636
|
1076 |
$\bullet$ & @{text "fv_ty\<^isub>i x\<^isub>i - bn_ty\<^isub>i x\<^isub>i"} provided @{text "x\<^isub>i"} is a deep recursive binder\\
|
1628
|
1077 |
\end{tabular}
|
|
1078 |
\end{center}
|
|
1079 |
|
1636
|
1080 |
\noindent
|
1637
|
1081 |
In case the argument @{text "x\<^isub>i"} is not a binder, it might be a body of
|
|
1082 |
one or more abstractions. There are two cases: either the
|
1636
|
1083 |
corresponding binders are all shallow or there is a single deep binder.
|
|
1084 |
In the former case we build the union of all shallow binders; in the
|
|
1085 |
later case we just take set or list of atoms the specified binding
|
1637
|
1086 |
function returns. Let @{text "bnds"} be an abbreviation of the bound
|
|
1087 |
atoms. Then the value is given by:
|
1636
|
1088 |
|
|
1089 |
\begin{center}
|
|
1090 |
\begin{tabular}{cp{7cm}}
|
|
1091 |
$\bullet$ & @{text "{atom x\<^isub>i} - bnds"} provided @{term "x\<^isub>i"} is an atom\\
|
|
1092 |
$\bullet$ & @{text "(atoms x\<^isub>i) - bnds"} provided @{term "x\<^isub>i"} is a set of atoms\\
|
1657
|
1093 |
$\bullet$ & @{text "(atoms (set x\<^isub>i)) - bnds"} provided @{term "x\<^isub>i"} is a list of atoms\\
|
1636
|
1094 |
$\bullet$ & @{text "(fv_ty\<^isub>i x\<^isub>i) - bnds"} provided @{term "ty\<^isub>i"} is a nominal datatype\\
|
|
1095 |
$\bullet$ & @{term "{}"} otherwise
|
|
1096 |
\end{tabular}
|
|
1097 |
\end{center}
|
1628
|
1098 |
|
1636
|
1099 |
\noindent
|
1637
|
1100 |
If the argument is neither a binder, nor a body of an abstraction, then the
|
|
1101 |
value is defined as above, except that @{text "bnds"} is empty. i.e.~no atoms
|
1636
|
1102 |
are abstracted.
|
1628
|
1103 |
|
1637
|
1104 |
TODO
|
|
1105 |
|
|
1106 |
Given a clause of a binding function of the form
|
|
1107 |
|
|
1108 |
\begin{center}
|
|
1109 |
@{text "bn_ty (C_raw x\<^isub>1 \<dots> x\<^isub>n) = rhs"}
|
|
1110 |
\end{center}
|
|
1111 |
|
|
1112 |
\noindent
|
|
1113 |
then the corresponding free-variable function @{text "fv_bn_ty\<^isub>i"} is the
|
|
1114 |
union of the values calculated for the @{text "x\<^isub>j"} as follows:
|
|
1115 |
|
|
1116 |
\begin{center}
|
|
1117 |
\begin{tabular}{cp{7cm}}
|
|
1118 |
$\bullet$ & @{text "{}"} provided @{term "x\<^isub>j"} occurs in @{text "rhs"} and is an atom\\
|
|
1119 |
$\bullet$ & @{text "fv_bn_ty x\<^isub>j"} provided @{term "x\<^isub>j"} occurs in @{text "rhs"}
|
|
1120 |
with the recursive call @{text "bn_ty x\<^isub>j"}\\
|
|
1121 |
$\bullet$ & @{text "(atoms x\<^isub>i) - bnds"} provided @{term "x\<^isub>i"} is a set of atoms\\
|
|
1122 |
$\bullet$ & @{text "(atoml x\<^isub>i) - bnds"} provided @{term "x\<^isub>i"} is a list of atoms\\
|
|
1123 |
$\bullet$ & @{text "(fv_ty\<^isub>i x\<^isub>i) - bnds"} provided @{term "ty\<^isub>i"} is a nominal datatype\\
|
|
1124 |
$\bullet$ & @{term "{}"} otherwise
|
|
1125 |
\end{tabular}
|
|
1126 |
\end{center}
|
|
1127 |
|
1587
|
1128 |
*}
|
|
1129 |
|
1637
|
1130 |
section {* The Lifting of Definitions and Properties *}
|
1587
|
1131 |
|
|
1132 |
text {*
|
1520
|
1133 |
Restrictions
|
|
1134 |
|
|
1135 |
\begin{itemize}
|
1572
|
1136 |
\item non-emptiness
|
1520
|
1137 |
\item positive datatype definitions
|
|
1138 |
\item finitely supported abstractions
|
|
1139 |
\item respectfulness of the bn-functions\bigskip
|
|
1140 |
\item binders can only have a ``single scope''
|
1577
|
1141 |
\item all bindings must have the same mode
|
1520
|
1142 |
\end{itemize}
|
|
1143 |
*}
|
|
1144 |
|
1493
|
1145 |
section {* Examples *}
|
1485
|
1146 |
|
1702
|
1147 |
text {*
|
|
1148 |
|
|
1149 |
\begin{figure}
|
|
1150 |
\begin{boxedminipage}{\linewidth}
|
|
1151 |
\small
|
|
1152 |
\begin{tabular}{l}
|
|
1153 |
\isacommand{atom\_decl}~@{text "var"}\\
|
|
1154 |
\isacommand{atom\_decl}~@{text "cvar"}\\
|
|
1155 |
\isacommand{atom\_decl}~@{text "tvar"}\\[1mm]
|
|
1156 |
\isacommand{nominal\_datatype}~@{text "tkind ="}\\
|
|
1157 |
\phantom{$|$}~@{text "KStar"}~$|$~@{text "KFun tkind tkind"}\\
|
|
1158 |
\isacommand{and}~@{text "ckind ="}\\
|
|
1159 |
\phantom{$|$}~@{text "CKSim ty ty"}\\
|
|
1160 |
\isacommand{and}~@{text "ty ="}\\
|
|
1161 |
\phantom{$|$}~@{text "TVar tvar"}~$|$~@{text "T string"}~$|$~@{text "TApp ty ty"}\\
|
|
1162 |
$|$~@{text "TFun string ty_list"}~%
|
|
1163 |
$|$~@{text "TAll tv::tvar tkind ty::ty"} \isacommand{bind}~@{text "tv"}~\isacommand{in}~@{text ty}\\
|
|
1164 |
$|$~@{text "TArr ckind ty"}\\
|
|
1165 |
\isacommand{and}~@{text "ty_lst ="}\\
|
|
1166 |
\phantom{$|$}~@{text "TNil"}~$|$~@{text "TCons ty ty_lst"}\\
|
|
1167 |
\isacommand{and}~@{text "cty ="}\\
|
|
1168 |
\phantom{$|$}~@{text "CVar cvar"}~%
|
|
1169 |
$|$~@{text "C string"}~$|$~@{text "CApp cty cty"}~$|$~@{text "CFun string co_lst"}\\
|
|
1170 |
$|$~@{text "CAll cv::cvar ckind cty::cty"} \isacommand{bind}~@{text "cv"}~\isacommand{in}~@{text cty}\\
|
|
1171 |
$|$~@{text "CArr ckind cty"}~$|$~@{text "CRefl ty"}~$|$~@{text "CSym cty"}~$|$~@{text "CCirc cty cty"}\\
|
|
1172 |
$|$~@{text "CAt cty ty"}~$|$~@{text "CLeft cty"}~$|$~@{text "CRight cty"}~$|$~@{text "CSim cty cty"}\\
|
|
1173 |
$|$~@{text "CRightc cty"}~$|$~@{text "CLeftc cty"}~$|$~@{text "Coerce cty cty"}\\
|
|
1174 |
\isacommand{and}~@{text "co_lst ="}\\
|
|
1175 |
\phantom{$|$}@{text "CNil"}~$|$~@{text "CCons cty co_lst"}\\
|
|
1176 |
\isacommand{and}~@{text "trm ="}\\
|
|
1177 |
\phantom{$|$}~@{text "Var var"}~$|$~@{text "K string"}\\
|
|
1178 |
$|$~@{text "LAM_ty tv::tvar tkind t::trm"} \isacommand{bind}~@{text "tv"}~\isacommand{in}~@{text t}\\
|
|
1179 |
$|$~@{text "LAM_cty cv::cvar ckind t::trm"} \isacommand{bind}~@{text "cv"}~\isacommand{in}~@{text t}\\
|
|
1180 |
$|$~@{text "App_ty trm ty"}~$|$~@{text "App_cty trm cty"}~$|$~@{text "App trm trm"}\\
|
|
1181 |
$|$~@{text "Lam v::var ty t::trm"} \isacommand{bind}~@{text "v"}~\isacommand{in}~@{text t}\\
|
|
1182 |
$|$~@{text "Let x::var ty trm t::trm"} \isacommand{bind}~{text x}~\isacommand{in}~{text t}\\
|
|
1183 |
$|$~@{text "Case trm assoc_lst"}~$|$~@{text "Cast trm co"}\\
|
|
1184 |
\isacommand{and}~@{text "assoc_lst ="}\\
|
|
1185 |
\phantom{$|$}~@{text ANil}~%
|
|
1186 |
$|$~@{text "ACons p::pat t::trm assoc_lst"} \isacommand{bind}~@{text "bv p"}~\isacommand{in}~@{text t}\\
|
|
1187 |
\isacommand{and}~@{text "pat ="}\\
|
|
1188 |
\phantom{$|$}~@{text "Kpat string tvtk_lst tvck_lst vt_lst"}\\
|
|
1189 |
\isacommand{and}~@{text "vt_lst ="}\\
|
|
1190 |
\phantom{$|$}~@{text VTNil}~$|$~@{text "VTCons var ty vt_lst"}\\
|
|
1191 |
\isacommand{and}~@{text "tvtk_lst ="}\\
|
|
1192 |
\phantom{$|$}~@{text TVTKNil}~$|$~@{text "TVTKCons tvar tkind tvtk_lst"}\\
|
|
1193 |
\isacommand{and}~@{text "tvck_lst ="}\\
|
|
1194 |
\phantom{$|$}~@{text TVCKNil}~$|$ @{text "TVCKCons cvar ckind tvck_lst"}\\
|
|
1195 |
\isacommand{binder}\\
|
|
1196 |
@{text "bv :: pat \<Rightarrow> atom list"}~\isacommand{and}~%
|
|
1197 |
@{text "bv1 :: vt_lst \<Rightarrow> atom list"}~\isacommand{and}\\
|
|
1198 |
@{text "bv2 :: tvtk_lst \<Rightarrow> atom list"}~\isacommand{and}~%
|
|
1199 |
@{text "bv3 :: tvck_lst \<Rightarrow> atom list"}\\
|
|
1200 |
\isacommand{where}\\
|
|
1201 |
\phantom{$|$}~@{text "bv (K s tvts tvcs vs) = (bv3 tvts) @ (bv2 tvcs) @ (bv1 vs)"}\\
|
|
1202 |
$|$~@{text "bv1 VTNil = []"}\\
|
|
1203 |
$|$~@{text "bv1 (VTCons x ty tl) = (atom x)::(bv1 tl)"}\\
|
|
1204 |
$|$~@{text "bv2 TVTKNil = []"}\\
|
|
1205 |
$|$~@{text "bv2 (TVTKCons a ty tl) = (atom a)::(bv2 tl)"}\\
|
|
1206 |
$|$~@{text "bv3 TVCKNil = []"}\\
|
|
1207 |
$|$~@{text "bv3 (TVCKCons c cty tl) = (atom c)::(bv3 tl)"}\\
|
|
1208 |
\end{tabular}
|
|
1209 |
\end{boxedminipage}
|
|
1210 |
\caption{\label{nominalcorehas}}
|
|
1211 |
\end{figure}
|
|
1212 |
*}
|
|
1213 |
|
|
1214 |
|
|
1215 |
|
|
1216 |
|
1517
62d6f7acc110
corrected the strong induction principle in the lambda-calculus case; gave a second (oartial) version that is more elegant
Christian Urban <urbanc@in.tum.de>
diff
changeset
|
1217 |
section {* Adequacy *}
|
62d6f7acc110
corrected the strong induction principle in the lambda-calculus case; gave a second (oartial) version that is more elegant
Christian Urban <urbanc@in.tum.de>
diff
changeset
|
1218 |
|
62d6f7acc110
corrected the strong induction principle in the lambda-calculus case; gave a second (oartial) version that is more elegant
Christian Urban <urbanc@in.tum.de>
diff
changeset
|
1219 |
section {* Related Work *}
|
62d6f7acc110
corrected the strong induction principle in the lambda-calculus case; gave a second (oartial) version that is more elegant
Christian Urban <urbanc@in.tum.de>
diff
changeset
|
1220 |
|
1570
|
1221 |
text {*
|
|
1222 |
Ott is better with list dot specifications; subgrammars
|
|
1223 |
|
|
1224 |
untyped;
|
|
1225 |
|
|
1226 |
*}
|
|
1227 |
|
|
1228 |
|
1493
|
1229 |
section {* Conclusion *}
|
1485
|
1230 |
|
|
1231 |
text {*
|
1520
|
1232 |
Complication when the single scopedness restriction is lifted (two
|
|
1233 |
overlapping permutations)
|
1662
|
1234 |
|
|
1235 |
|
|
1236 |
The formalisation presented here will eventually become part of the
|
|
1237 |
Isabelle distribution, but for the moment it can be downloaded from
|
|
1238 |
the Mercurial repository linked at
|
|
1239 |
\href{http://isabelle.in.tum.de/nominal/download}
|
|
1240 |
{http://isabelle.in.tum.de/nominal/download}.\medskip
|
1520
|
1241 |
*}
|
|
1242 |
|
|
1243 |
text {*
|
1493
|
1244 |
|
1517
62d6f7acc110
corrected the strong induction principle in the lambda-calculus case; gave a second (oartial) version that is more elegant
Christian Urban <urbanc@in.tum.de>
diff
changeset
|
1245 |
TODO: function definitions:
|
62d6f7acc110
corrected the strong induction principle in the lambda-calculus case; gave a second (oartial) version that is more elegant
Christian Urban <urbanc@in.tum.de>
diff
changeset
|
1246 |
\medskip
|
62d6f7acc110
corrected the strong induction principle in the lambda-calculus case; gave a second (oartial) version that is more elegant
Christian Urban <urbanc@in.tum.de>
diff
changeset
|
1247 |
|
1493
|
1248 |
\noindent
|
1528
|
1249 |
{\bf Acknowledgements:} We are very grateful to Andrew Pitts for
|
1506
|
1250 |
many discussions about Nominal Isabelle. We thank Peter Sewell for
|
|
1251 |
making the informal notes \cite{SewellBestiary} available to us and
|
1556
|
1252 |
also for patiently explaining some of the finer points about the abstract
|
1702
|
1253 |
definitions and about the implementation of the Ott-tool. We
|
|
1254 |
also thank Stephanie Weirich for suggesting to separate the subgrammars
|
|
1255 |
of kinds and types in our Core-Haskell example.
|
1485
|
1256 |
|
1577
|
1257 |
Lookup: Merlin paper by James Cheney; Mark Shinwell PhD
|
754
|
1258 |
|
1577
|
1259 |
Future work: distinct list abstraction
|
|
1260 |
|
|
1261 |
|
754
|
1262 |
*}
|
|
1263 |
|
1484
|
1264 |
|
|
1265 |
|
754
|
1266 |
(*<*)
|
|
1267 |
end
|
|
1268 |
(*>*) |