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
|
1506
|
16 |
fresh_star ("_ #* _" [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
|
|
50 |
\cite{BengtsonParrow07,BengtsonParow09} and a strong normalisation result
|
|
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,
|
1628
|
331 |
only works if alpha-equivalence is indeed an equivalence relation, and the lifted
|
1693
|
332 |
definitions and theorems are respectful w.r.t.~alpha-equivalence. For example, we
|
1667
|
333 |
will not be able to lift a bound-variable function, which can be defined for
|
1687
|
334 |
raw terms. The reason is that this function does not respect alpha-equivalence.
|
|
335 |
To sum up, every lifting of
|
1607
|
336 |
theorems to the quotient level needs proofs of some respectfulness
|
1687
|
337 |
properties (see \cite{Homeier05}). In the paper we show that we are able to
|
|
338 |
automate these
|
1607
|
339 |
proofs and therefore can establish a reasoning infrastructure for
|
1667
|
340 |
alpha-equated terms.
|
|
341 |
|
|
342 |
The examples we have in mind where our reasoning infrastructure will be
|
1690
|
343 |
helpful includes the term language of System @{text "F\<^isub>C"}, also known as
|
|
344 |
Core-Haskell (see Figure~\ref{corehas}). This term language involves patterns
|
|
345 |
that include lists of
|
1667
|
346 |
type- and term- variables (the arguments of constructors) all of which are
|
|
347 |
bound in case expressions. One difficulty is that each of these variables
|
|
348 |
come with a kind or type annotation. Representing such binders with single
|
|
349 |
binders and reasoning about them in a theorem prover would be a major pain.
|
|
350 |
\medskip
|
1577
|
351 |
|
1506
|
352 |
|
1528
|
353 |
\noindent
|
|
354 |
{\bf Contributions:} We provide new definitions for when terms
|
|
355 |
involving multiple binders are alpha-equivalent. These definitions are
|
1607
|
356 |
inspired by earlier work of Pitts \cite{Pitts04}. By means of automatic
|
1528
|
357 |
proofs, we establish a reasoning infrastructure for alpha-equated
|
|
358 |
terms, including properties about support, freshness and equality
|
1607
|
359 |
conditions for alpha-equated terms. We are also able to derive, at the moment
|
|
360 |
only manually, strong induction principles that
|
|
361 |
have the variable convention already built in.
|
1667
|
362 |
|
|
363 |
\begin{figure}
|
1687
|
364 |
\begin{boxedminipage}{\linewidth}
|
|
365 |
\begin{center}
|
1693
|
366 |
\begin{tabular}{r@ {\hspace{2mm}}cl}
|
1690
|
367 |
\multicolumn{3}{@ {}l}{Type Kinds}\\
|
|
368 |
@{text "\<kappa>"} & @{text "::="} & @{text "\<star> | \<kappa>\<^isub>1 \<rightarrow> \<kappa>\<^isub>2"}\medskip\\
|
|
369 |
\multicolumn{3}{@ {}l}{Coercion Kinds}\\
|
|
370 |
@{text "\<iota>"} & @{text "::="} & @{text "\<sigma>\<^isub>1 \<sim> \<sigma>\<^isub>2"}\medskip\\
|
|
371 |
\multicolumn{3}{@ {}l}{Types}\\
|
|
372 |
@{text "\<sigma>"} & @{text "::="} & @{text "a | T | \<sigma>\<^isub>1 \<sigma>\<^isub>2 | S\<^isub>n"}$\;\overline{@{text "\<sigma>"}}$@{text "\<^sup>n"}\\
|
|
373 |
& & @{text "| \<forall>a:\<kappa>. \<sigma> "}\\
|
|
374 |
& & ??? Type equality\medskip\\
|
|
375 |
\multicolumn{3}{@ {}l}{Coercion Types}\\
|
|
376 |
@{text "\<gamma>"} & @{text "::="} & @{text "a | C | S\<^isub>n"}$\;\overline{@{text "\<gamma>"}}$@{text "\<^sup>n"}\\
|
|
377 |
& & @{text "| \<forall>a:\<iota>. \<gamma>"}\\
|
|
378 |
& & ??? Coercion Type equality\\
|
|
379 |
& & @{text "| sym \<gamma> | \<gamma>\<^isub>1 \<circ> \<gamma>\<^isub>2 | left \<gamma> | right \<gamma> | \<gamma>\<^isub>1 \<sim> \<gamma>\<^isub>2 "}\\
|
|
380 |
& & @{text "| rightc \<gamma> | leftc \<gamma> | \<gamma>\<^isub>1 \<triangleright> \<gamma>\<^isub>2"}\medskip\\
|
|
381 |
\multicolumn{3}{@ {}l}{Terms}\\
|
|
382 |
@{text "e"} & @{text "::="} & @{text "x | K | \<Lambda>a:\<kappa>. e | \<Lambda>a:\<iota>. e | e \<sigma> | e \<gamma> |"}\\
|
|
383 |
& & @{text "\<lambda>x:\<sigma>.e | e\<^isub>1 e\<^isub>2 | \<LET> x:\<sigma> = e\<^isub>1 \<IN> e\<^isub>2 |"}\\
|
|
384 |
& & @{text "\<CASE> e\<^isub>1 \<OF>"}$\;\overline{@{text "p \<rightarrow> e\<^isub>2"}}$ @{text "| e \<triangleright> \<gamma>"}\medskip\\
|
|
385 |
\multicolumn{3}{@ {}l}{Patterns}\\
|
1693
|
386 |
@{text "p"} & @{text "::="} & @{text "K"}$\;\overline{@{text "a:\<kappa>"}}\;\overline{@{text "a:\<iota>"}}\;\overline{@{text "x:\<sigma>"}}$\medskip\\
|
1690
|
387 |
\multicolumn{3}{@ {}l}{Constants}\\
|
|
388 |
@{text C} & & coercion constant\\
|
|
389 |
@{text T} & & value type constructor\\
|
|
390 |
@{text "S\<^isub>n"} & & n-ary type function\\
|
|
391 |
@{text K} & & data constructor\medskip\\
|
|
392 |
\multicolumn{3}{@ {}l}{Variables}\\
|
|
393 |
@{text a} & & type variable\\
|
|
394 |
@{text x} & & term variable\\
|
1687
|
395 |
\end{tabular}
|
|
396 |
\end{center}
|
|
397 |
\end{boxedminipage}
|
|
398 |
\caption{The term-language of System @{text "F\<^isub>C"}, also often referred to as Core-Haskell,
|
1693
|
399 |
according to \cite{CoreHaskell}. We only made an inessential modification by
|
1687
|
400 |
separating the grammars for type kinds and coercion types.\label{corehas}}
|
1667
|
401 |
\end{figure}
|
1485
|
402 |
*}
|
|
403 |
|
1493
|
404 |
section {* A Short Review of the Nominal Logic Work *}
|
|
405 |
|
|
406 |
text {*
|
1556
|
407 |
At its core, Nominal Isabelle is an adaption of the nominal logic work by
|
|
408 |
Pitts \cite{Pitts03}. This adaptation for Isabelle/HOL is described in
|
1690
|
409 |
\cite{HuffmanUrban10} (including proofs), which we review here briefly to aid the description
|
1556
|
410 |
of what follows. Two central notions in the nominal logic work are sorted
|
1570
|
411 |
atoms and sort-respecting permutations of atoms. The sorts can be used to
|
1690
|
412 |
represent different kinds of variables, such as the term- and type-variables in
|
1570
|
413 |
Core-Haskell, and it is assumed that there is an infinite supply of atoms
|
|
414 |
for each sort. However, in order to simplify the description, we shall
|
1617
|
415 |
assume in what follows that there is only one sort of atoms.
|
1493
|
416 |
|
|
417 |
Permutations are bijective functions from atoms to atoms that are
|
|
418 |
the identity everywhere except on a finite number of atoms. There is a
|
|
419 |
two-place permutation operation written
|
1617
|
420 |
%
|
|
421 |
@{text[display,indent=5] "_ \<bullet> _ :: perm \<Rightarrow> \<beta> \<Rightarrow> \<beta>"}
|
1493
|
422 |
|
|
423 |
\noindent
|
1628
|
424 |
in which the generic type @{text "\<beta>"} stands for the type of the object
|
1617
|
425 |
on which the permutation
|
|
426 |
acts. In Nominal Isabelle, the identity permutation is written as @{term "0::perm"},
|
1690
|
427 |
the composition of two permutations @{term p} and @{term q} as \mbox{@{term "p + q"}},
|
1570
|
428 |
and the inverse permutation of @{term p} as @{text "- p"}. The permutation
|
1690
|
429 |
operation is defined for products, lists, sets, functions, booleans etc (see \cite{HuffmanUrban10})
|
|
430 |
|
|
431 |
\begin{center}
|
|
432 |
\begin{tabular}{@ {}cc@ {}}
|
|
433 |
\begin{tabular}{@ {}l@ {}}
|
|
434 |
@{thm permute_prod.simps[no_vars, THEN eq_reflection]}\\[2mm]
|
|
435 |
@{thm permute_list.simps(1)[no_vars, THEN eq_reflection]}\\
|
|
436 |
@{thm permute_list.simps(2)[no_vars, THEN eq_reflection]}\\
|
|
437 |
\end{tabular} &
|
|
438 |
\begin{tabular}{@ {}l@ {}}
|
|
439 |
@{thm permute_set_eq[no_vars, THEN eq_reflection]}\\
|
|
440 |
@{text "p \<bullet> (f x) \<equiv> (p \<bullet> f) (p \<bullet> x)"}\\
|
|
441 |
@{thm permute_bool_def[no_vars, THEN eq_reflection]}\\
|
|
442 |
\end{tabular}
|
|
443 |
\end{tabular}
|
|
444 |
\end{center}
|
|
445 |
|
|
446 |
\noindent
|
|
447 |
Concrete permutations are build up from
|
1628
|
448 |
swappings, written as @{text "(a b)"},
|
1617
|
449 |
which are permutations that behave as follows:
|
|
450 |
%
|
|
451 |
@{text[display,indent=5] "(a b) = \<lambda>c. if a = c then b else if b = c then a else c"}
|
|
452 |
|
1570
|
453 |
The most original aspect of the nominal logic work of Pitts is a general
|
|
454 |
definition for the notion of ``the set of free variables of an object @{text
|
|
455 |
"x"}''. This notion, written @{term "supp x"}, is general in the sense that
|
1628
|
456 |
it applies not only to lambda-terms (alpha-equated or not), but also to lists,
|
1570
|
457 |
products, sets and even functions. The definition depends only on the
|
|
458 |
permutation operation and on the notion of equality defined for the type of
|
|
459 |
@{text x}, namely:
|
1617
|
460 |
%
|
1506
|
461 |
@{thm[display,indent=5] supp_def[no_vars, THEN eq_reflection]}
|
1493
|
462 |
|
|
463 |
\noindent
|
|
464 |
There is also the derived notion for when an atom @{text a} is \emph{fresh}
|
|
465 |
for an @{text x}, defined as
|
1617
|
466 |
%
|
1506
|
467 |
@{thm[display,indent=5] fresh_def[no_vars]}
|
1493
|
468 |
|
|
469 |
\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
|
470 |
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
|
471 |
@{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
|
472 |
@{thm (rhs) fresh_star_def[no_vars]}.
|
1493
|
473 |
A striking consequence of these definitions is that we can prove
|
|
474 |
without knowing anything about the structure of @{term x} that
|
|
475 |
swapping two fresh atoms, say @{text a} and @{text b}, leave
|
1506
|
476 |
@{text x} unchanged.
|
|
477 |
|
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
|
478 |
\begin{property}
|
1506
|
479 |
@{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
|
480 |
\end{property}
|
1506
|
481 |
|
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 |
\noindent
|
1690
|
483 |
While it is often clear what the support for a construction is, for
|
|
484 |
example
|
|
485 |
%
|
|
486 |
\begin{eqnarray}
|
|
487 |
@{term "supp (x, y)"} & = & @{term "supp x \<union> supp y"}\\
|
|
488 |
@{term "supp []"} & = & @{term "{}"}\\
|
|
489 |
@{term "supp (x#xs)"} & = & @{term "supp (x, xs)"}\\
|
|
490 |
@{text "supp (f x)"} & @{text "\<subseteq>"} & @{term "supp (f, x)"}\\
|
|
491 |
@{term "supp b"} & = & @{term "{}"}
|
|
492 |
\end{eqnarray}
|
|
493 |
|
|
494 |
\noindent
|
|
495 |
it can sometimes be difficult to establish the support precisely,
|
|
496 |
and only give an over approximation (see functions above). This
|
|
497 |
over approximation can be formalised with the notions \emph{supports},
|
1693
|
498 |
defined as follows.
|
|
499 |
|
|
500 |
\begin{defn}
|
|
501 |
A set @{text S} \emph{supports} @{text x} if for all atoms @{text a} and @{text b}
|
|
502 |
not in @{text S} we have @{term "(a \<rightleftharpoons> b) \<bullet> x = x"}.
|
|
503 |
\end{defn}
|
1690
|
504 |
|
1693
|
505 |
\noindent
|
|
506 |
The point of this definitions is that we can show:
|
|
507 |
|
|
508 |
\begin{property}
|
|
509 |
{\it i)} @{thm[mode=IfThen] supp_is_subset[no_vars]}
|
|
510 |
{\it ii)} @{thm supp_supports[no_vars]}.
|
|
511 |
\end{property}
|
|
512 |
|
|
513 |
\noindent
|
|
514 |
Another important notion in the nominal logic work is \emph{equivariance}.
|
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
|
515 |
|
1662
|
516 |
%\begin{property}
|
|
517 |
%@{thm[mode=IfThen] at_set_avoiding[no_vars]}
|
|
518 |
%\end{property}
|
1493
|
519 |
|
|
520 |
*}
|
|
521 |
|
1485
|
522 |
|
1620
|
523 |
section {* General Binders\label{sec:binders} *}
|
1485
|
524 |
|
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
|
525 |
text {*
|
1587
|
526 |
In Nominal Isabelle, the user is expected to write down a specification of a
|
|
527 |
term-calculus and then a reasoning infrastructure is automatically derived
|
1617
|
528 |
from this specification (remember that Nominal Isabelle is a definitional
|
1587
|
529 |
extension of Isabelle/HOL, which does not introduce any new axioms).
|
1579
|
530 |
|
1657
|
531 |
In order to keep our work with deriving the reasoning infrastructure
|
|
532 |
manageable, we will wherever possible state definitions and perform proofs
|
|
533 |
on the user-level of Isabelle/HOL, as opposed to write custom ML-code that
|
|
534 |
generates them anew for each specification. To that end, we will consider
|
|
535 |
first pairs @{text "(as, x)"} of type @{text "(atom set) \<times> \<beta>"}. These pairs
|
|
536 |
are intended to represent the abstraction, or binding, of the set @{text
|
|
537 |
"as"} in the body @{text "x"}.
|
1570
|
538 |
|
1657
|
539 |
The first question we have to answer is when the pairs @{text "(as, x)"} and
|
|
540 |
@{text "(bs, y)"} are alpha-equivalent? (At the moment we are interested in
|
|
541 |
the notion of alpha-equivalence that is \emph{not} preserved by adding
|
|
542 |
vacuous binders.) To answer this, we identify four conditions: {\it i)}
|
|
543 |
given a free-variable function @{text "fv"} of type \mbox{@{text "\<beta> \<Rightarrow> atom
|
|
544 |
set"}}, then @{text x} and @{text y} need to have the same set of free
|
|
545 |
variables; moreover there must be a permutation @{text p} such that {\it
|
1687
|
546 |
ii)} @{text p} leaves the free variables of @{text x} and @{text y} unchanged, but
|
1657
|
547 |
{\it iii)} ``moves'' their bound names so that we obtain modulo a relation,
|
1662
|
548 |
say \mbox{@{text "_ R _"}}, two equivalent terms. We also require {\it iv)} that
|
|
549 |
@{text p} makes the sets of abstracted atoms @{text as} and @{text bs} equal. The
|
1657
|
550 |
requirements {\it i)} to {\it iv)} can be stated formally as follows:
|
1556
|
551 |
%
|
1572
|
552 |
\begin{equation}\label{alphaset}
|
|
553 |
\begin{array}{@ {\hspace{10mm}}r@ {\hspace{2mm}}l}
|
1687
|
554 |
\multicolumn{2}{l}{@{term "(as, x) \<approx>gen R fv p (bs, y)"}\hspace{2mm}@{text "\<equiv>"}\hspace{30mm}}\\[1mm]
|
1657
|
555 |
& @{term "fv(x) - as = fv(y) - bs"}\\
|
|
556 |
@{text "\<and>"} & @{term "(fv(x) - as) \<sharp>* p"}\\
|
|
557 |
@{text "\<and>"} & @{text "(p \<bullet> x) R y"}\\
|
|
558 |
@{text "\<and>"} & @{term "(p \<bullet> as) = bs"}\\
|
1572
|
559 |
\end{array}
|
1556
|
560 |
\end{equation}
|
|
561 |
|
|
562 |
\noindent
|
1657
|
563 |
Note that this relation is dependent on the permutation @{text
|
|
564 |
"p"}. Alpha-equivalence between two pairs is then the relation where we
|
|
565 |
existentially quantify over this @{text "p"}. Also note that the relation is
|
|
566 |
dependent on a free-variable function @{text "fv"} and a relation @{text
|
|
567 |
"R"}. The reason for this extra generality is that we will use
|
|
568 |
$\approx_{\textit{set}}$ for both ``raw'' terms and alpha-equated terms. In
|
|
569 |
the latter case, $R$ will be replaced by equality @{text "="} and for raw terms we
|
|
570 |
will prove that @{text "fv"} is equal to the support of @{text
|
|
571 |
x} and @{text y}.
|
1572
|
572 |
|
|
573 |
The definition in \eqref{alphaset} does not make any distinction between the
|
1579
|
574 |
order of abstracted variables. If we want this, then we can define alpha-equivalence
|
|
575 |
for pairs of the form \mbox{@{text "(as, x)"}} with type @{text "(atom list) \<times> \<beta>"}
|
|
576 |
as follows
|
1572
|
577 |
%
|
|
578 |
\begin{equation}\label{alphalist}
|
|
579 |
\begin{array}{@ {\hspace{10mm}}r@ {\hspace{2mm}}l}
|
1687
|
580 |
\multicolumn{2}{l}{@{term "(as, x) \<approx>lst R fv p (bs, y)"}\hspace{2mm}@{text "\<equiv>"}\hspace{30mm}}\\[1mm]
|
1657
|
581 |
& @{term "fv(x) - (set as) = fv(y) - (set bs)"}\\
|
|
582 |
\wedge & @{term "(fv(x) - set as) \<sharp>* p"}\\
|
1572
|
583 |
\wedge & @{text "(p \<bullet> x) R y"}\\
|
1657
|
584 |
\wedge & @{term "(p \<bullet> as) = bs"}\\
|
1572
|
585 |
\end{array}
|
|
586 |
\end{equation}
|
|
587 |
|
|
588 |
\noindent
|
1657
|
589 |
where @{term set} is a function that coerces a list of atoms into a set of atoms.
|
|
590 |
Now the last clause ensures that the order of the binders matters.
|
1556
|
591 |
|
1657
|
592 |
If we do not want to make any difference between the order of binders \emph{and}
|
1579
|
593 |
also allow vacuous binders, then we keep sets of binders, but drop the fourth
|
|
594 |
condition in \eqref{alphaset}:
|
1572
|
595 |
%
|
1579
|
596 |
\begin{equation}\label{alphares}
|
1572
|
597 |
\begin{array}{@ {\hspace{10mm}}r@ {\hspace{2mm}}l}
|
1687
|
598 |
\multicolumn{2}{l}{@{term "(as, x) \<approx>res R fv p (bs, y)"}\hspace{2mm}@{text "\<equiv>"}\hspace{30mm}}\\[1mm]
|
1657
|
599 |
& @{term "fv(x) - as = fv(y) - bs"}\\
|
|
600 |
\wedge & @{term "(fv(x) - as) \<sharp>* p"}\\
|
1572
|
601 |
\wedge & @{text "(p \<bullet> x) R y"}\\
|
|
602 |
\end{array}
|
|
603 |
\end{equation}
|
1556
|
604 |
|
1662
|
605 |
It might be useful to consider some examples for how these definitions of alpha-equivalence
|
|
606 |
pan out in practise.
|
1579
|
607 |
For this consider the case of abstracting a set of variables over types (as in type-schemes).
|
1657
|
608 |
We set @{text R} to be the equality and for @{text "fv(T)"} we define
|
1572
|
609 |
|
|
610 |
\begin{center}
|
1657
|
611 |
@{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
|
612 |
\end{center}
|
|
613 |
|
|
614 |
\noindent
|
1657
|
615 |
Now recall the examples shown in \eqref{ex1}, \eqref{ex2} and
|
1687
|
616 |
\eqref{ex3}. It can be easily checked that @{text "({x, y}, x \<rightarrow> y)"} and
|
|
617 |
@{text "({y, x}, y \<rightarrow> x)"} are equal according to $\approx_{\textit{set}}$ and
|
1657
|
618 |
$\approx_{\textit{res}}$ by taking @{text p} to be the swapping @{term "(x \<rightleftharpoons>
|
|
619 |
y)"}. In case of @{text "x \<noteq> y"}, then @{text "([x, y], x \<rightarrow> y)"}
|
1687
|
620 |
$\not\approx_{\textit{list}}$ @{text "([y, x], x \<rightarrow> y)"} since there is no permutation
|
1657
|
621 |
that makes the lists @{text "[x, y]"} and @{text "[y, x]"} equal, and also
|
|
622 |
leaves the type \mbox{@{text "x \<rightarrow> y"}} unchanged. Another example is
|
1687
|
623 |
@{text "({x}, x)"} $\approx_{\textit{res}}$ @{text "({x, y}, x)"} which holds by
|
1657
|
624 |
taking @{text p} to be the
|
|
625 |
identity permutation. However, if @{text "x \<noteq> y"}, then @{text "({x}, x)"}
|
1687
|
626 |
$\not\approx_{\textit{set}}$ @{text "({x, y}, x)"} since there is no permutation
|
1657
|
627 |
that makes the
|
1687
|
628 |
sets @{text "{x}"} and @{text "{x, y}"} equal (similarly for $\approx_{\textit{list}}$).
|
|
629 |
It can also relatively easily be shown that all tree notions of alpha-equivalence
|
|
630 |
coincide, if we only abstract a single atom.
|
1579
|
631 |
|
1657
|
632 |
% looks too ugly
|
|
633 |
%\noindent
|
|
634 |
%Let $\star$ range over $\{set, res, list\}$. We prove next under which
|
|
635 |
%conditions the $\approx\hspace{0.05mm}_\star^{\fv, R, p}$ are equivalence
|
|
636 |
%relations and equivariant:
|
|
637 |
%
|
|
638 |
%\begin{lemma}
|
|
639 |
%{\it i)} Given the fact that $x\;R\;x$ holds, then
|
|
640 |
%$(as, x) \approx\hspace{0.05mm}^{\fv, R, 0}_\star (as, x)$. {\it ii)} Given
|
|
641 |
%that @{text "(p \<bullet> x) R y"} implies @{text "(-p \<bullet> y) R x"}, then
|
|
642 |
%$(as, x) \approx\hspace{0.05mm}^{\fv, R, p}_\star (bs, y)$ implies
|
|
643 |
%$(bs, y) \approx\hspace{0.05mm}^{\fv, R, - p}_\star (as, x)$. {\it iii)} Given
|
|
644 |
%that @{text "(p \<bullet> x) R y"} and @{text "(q \<bullet> y) R z"} implies
|
|
645 |
%@{text "((q + p) \<bullet> x) R z"}, then $(as, x) \approx\hspace{0.05mm}^{\fv, R, p}_\star (bs, y)$
|
|
646 |
%and $(bs, y) \approx\hspace{0.05mm}^{\fv, R, q}_\star (cs, z)$ implies
|
|
647 |
%$(as, x) \approx\hspace{0.05mm}^{\fv, R, q + p}_\star (cs, z)$. Given
|
|
648 |
%@{text "(q \<bullet> x) R y"} implies @{text "(p \<bullet> (q \<bullet> x)) R (p \<bullet> y)"} and
|
|
649 |
%@{text "p \<bullet> (fv x) = fv (p \<bullet> x)"} then @{text "p \<bullet> (fv y) = fv (p \<bullet> y)"}, then
|
|
650 |
%$(as, x) \approx\hspace{0.05mm}^{\fv, R, q}_\star (bs, y)$ implies
|
|
651 |
%$(p \;\isasymbullet\; as, p \;\isasymbullet\; x) \approx\hspace{0.05mm}^{\fv, R, q}_\star
|
|
652 |
%(p \;\isasymbullet\; bs, p \;\isasymbullet\; y)$.
|
|
653 |
%\end{lemma}
|
|
654 |
|
|
655 |
%\begin{proof}
|
|
656 |
%All properties are by unfolding the definitions and simple calculations.
|
|
657 |
%\end{proof}
|
|
658 |
|
|
659 |
|
1687
|
660 |
In the rest of this section we are going to introduce a type- and term-constructors
|
|
661 |
for abstraction. For this we define
|
1657
|
662 |
%
|
|
663 |
\begin{equation}
|
|
664 |
@{term "abs_set (as, x) (bs, x) \<equiv> \<exists>p. alpha_gen (as, x) equal supp p (bs, x)"}
|
|
665 |
\end{equation}
|
|
666 |
|
1579
|
667 |
\noindent
|
1687
|
668 |
(similarly for $\approx_{\textit{abs\_list}}$
|
|
669 |
and $\approx_{\textit{abs\_res}}$). We can show that these relations are equivalence
|
|
670 |
relations and equivariant.
|
1579
|
671 |
|
1687
|
672 |
\begin{lemma}\label{alphaeq} The relations
|
|
673 |
$\approx_{\textit{abs\_set}}$,
|
|
674 |
$\approx_{\textit{abs\_list}}$
|
|
675 |
and $\approx_{\textit{abs\_res}}$
|
|
676 |
are equivalence
|
1662
|
677 |
relations, and if @{term "abs_set (as, x) (bs, y)"} then also
|
1687
|
678 |
@{term "abs_set (p \<bullet> as, p \<bullet> x) (p \<bullet> bs, p \<bullet> y)"} (similarly for
|
|
679 |
the other two relations).
|
1657
|
680 |
\end{lemma}
|
|
681 |
|
|
682 |
\begin{proof}
|
|
683 |
Reflexivity is by taking @{text "p"} to be @{text "0"}. For symmetry we have
|
|
684 |
a permutation @{text p} and for the proof obligation take @{term "-p"}. In case
|
1662
|
685 |
of transitivity, we have two permutations @{text p} and @{text q}, and for the
|
|
686 |
proof obligation use @{text "q + p"}. All conditions are then by simple
|
1657
|
687 |
calculations.
|
|
688 |
\end{proof}
|
|
689 |
|
|
690 |
\noindent
|
1687
|
691 |
This lemma allows us to use our quotient package and introduce
|
1662
|
692 |
new types @{text "\<beta> abs_set"}, @{text "\<beta> abs_res"} and @{text "\<beta> abs_list"}
|
1687
|
693 |
representing alpha-equivalence classes of pairs. The elements in these types
|
1657
|
694 |
we will, respectively, write as:
|
|
695 |
|
|
696 |
\begin{center}
|
|
697 |
@{term "Abs as x"} \hspace{5mm}
|
|
698 |
@{term "Abs_lst as x"} \hspace{5mm}
|
|
699 |
@{term "Abs_res as x"}
|
|
700 |
\end{center}
|
|
701 |
|
1662
|
702 |
\noindent
|
1687
|
703 |
indicating that a set or list is abstracted in @{text x}. We will call the types
|
|
704 |
\emph{abstraction types} and their elements \emph{abstractions}. The important
|
|
705 |
property we need is a characterisation for the support of abstractions, namely
|
1662
|
706 |
|
1687
|
707 |
\begin{thm}[Support of Abstractions]\label{suppabs}
|
|
708 |
Assuming @{text x} has finite support, then
|
1662
|
709 |
\begin{center}
|
1687
|
710 |
\begin{tabular}{l@ {\hspace{2mm}}c@ {\hspace{2mm}}l}
|
|
711 |
@{thm (lhs) supp_abs(1)[no_vars]} & $=$ & @{thm (rhs) supp_abs(1)[no_vars]}\\
|
|
712 |
@{thm (lhs) supp_abs(2)[no_vars]} & $=$ & @{thm (rhs) supp_abs(2)[no_vars]}\\
|
|
713 |
@{thm (lhs) supp_abs(3)[no_vars]} & $=$ & @{thm (rhs) supp_abs(3)[no_vars]}
|
|
714 |
\end{tabular}
|
1662
|
715 |
\end{center}
|
1687
|
716 |
\end{thm}
|
1662
|
717 |
|
|
718 |
\noindent
|
1687
|
719 |
We will only show in the rest of the section the first equation, as the others
|
|
720 |
follow similar arguments. By definition of the abstraction type @{text "abs_set"}
|
|
721 |
we have
|
|
722 |
%
|
|
723 |
\begin{equation}\label{abseqiff}
|
|
724 |
@{thm (lhs) abs_eq_iff(1)[where bs="as" and cs="bs", no_vars]} \;\text{if and only if}\;
|
|
725 |
@{thm (rhs) abs_eq_iff(1)[where bs="as" and cs="bs", no_vars]}
|
|
726 |
\end{equation}
|
|
727 |
|
|
728 |
\noindent
|
|
729 |
With this, we can show the following lemma about swapping two atoms (the permutation
|
|
730 |
operation for abstractions is the one lifted for pairs).\footnote{metion this in the nominal
|
|
731 |
logic section}
|
1662
|
732 |
|
|
733 |
\begin{lemma}
|
|
734 |
@{thm[mode=IfThen] abs_swap1(1)[no_vars]}
|
|
735 |
\end{lemma}
|
|
736 |
|
|
737 |
\begin{proof}
|
1687
|
738 |
By using \eqref{abseqiff}, this lemma is straightforward when observing that
|
|
739 |
the assumptions give us
|
1662
|
740 |
@{term "(a \<rightleftharpoons> b) \<bullet> (supp x - bs) = (supp x - bs)"} and that @{text supp}
|
1687
|
741 |
and set difference are equivariant.
|
1662
|
742 |
\end{proof}
|
1587
|
743 |
|
1687
|
744 |
\noindent
|
|
745 |
This lemma gives us
|
|
746 |
%
|
|
747 |
\begin{equation}\label{halfone}
|
|
748 |
@{thm abs_supports(1)[no_vars]}
|
|
749 |
\end{equation}
|
|
750 |
|
|
751 |
\noindent
|
|
752 |
which with \ref{} gives us one half of Thm~\ref{suppabs}. The other half is
|
|
753 |
a bit more involved. We first define an auxiliary function
|
|
754 |
%
|
|
755 |
\begin{center}
|
|
756 |
@{thm supp_res.simps[THEN eq_reflection, no_vars]}
|
|
757 |
\end{center}
|
|
758 |
|
|
759 |
|
1587
|
760 |
\begin{lemma}
|
|
761 |
$supp ([as]set. x) = supp x - as$
|
|
762 |
\end{lemma}
|
1687
|
763 |
|
|
764 |
\noindent
|
|
765 |
The point of these general lemmas about pairs is that we can define and prove properties
|
1693
|
766 |
about them conveniently on the Isabelle level, and in addition can use them in what
|
1687
|
767 |
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
|
768 |
*}
|
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
|
769 |
|
1491
|
770 |
section {* Alpha-Equivalence and Free Variables *}
|
|
771 |
|
1520
|
772 |
text {*
|
1637
|
773 |
Our specifications for term-calculi are heavily inspired by the existing
|
|
774 |
datatype package of Isabelle/HOL and by the syntax of the Ott-tool
|
|
775 |
\cite{ott-jfp}. A specification is a collection of (possibly mutual
|
|
776 |
recursive) type declarations, say @{text "ty"}$^\alpha_1$, \ldots,
|
|
777 |
@{text ty}$^\alpha_n$, and an associated collection
|
|
778 |
of binding functions, say @{text bn}$^\alpha_1$, \ldots, @{text
|
|
779 |
bn}$^\alpha_m$. The syntax in Nominal Isabelle for such specifications is
|
1693
|
780 |
roughly as follows:
|
1628
|
781 |
%
|
1619
|
782 |
\begin{equation}\label{scheme}
|
1636
|
783 |
\mbox{\begin{tabular}{@ {\hspace{-5mm}}p{1.8cm}l}
|
1617
|
784 |
type \mbox{declaration part} &
|
1611
|
785 |
$\begin{cases}
|
|
786 |
\mbox{\begin{tabular}{l}
|
1637
|
787 |
\isacommand{nominal\_datatype} @{text ty}$^\alpha_1 = \ldots$\\
|
|
788 |
\isacommand{and} @{text ty}$^\alpha_2 = \ldots$\\
|
1587
|
789 |
$\ldots$\\
|
1637
|
790 |
\isacommand{and} @{text ty}$^\alpha_n = \ldots$\\
|
1611
|
791 |
\end{tabular}}
|
|
792 |
\end{cases}$\\
|
1617
|
793 |
binding \mbox{function part} &
|
1611
|
794 |
$\begin{cases}
|
|
795 |
\mbox{\begin{tabular}{l}
|
1637
|
796 |
\isacommand{with} @{text bn}$^\alpha_1$ \isacommand{and} \ldots \isacommand{and} @{text bn}$^\alpha_m$\\
|
1611
|
797 |
\isacommand{where}\\
|
1587
|
798 |
$\ldots$\\
|
1611
|
799 |
\end{tabular}}
|
|
800 |
\end{cases}$\\
|
1619
|
801 |
\end{tabular}}
|
|
802 |
\end{equation}
|
1587
|
803 |
|
|
804 |
\noindent
|
1637
|
805 |
Every type declaration @{text ty}$^\alpha_{1..n}$ consists of a collection of
|
1611
|
806 |
term-constructors, each of which comes with a list of labelled
|
1620
|
807 |
types that stand for the types of the arguments of the term-constructor.
|
1637
|
808 |
For example a term-constructor @{text "C\<^sup>\<alpha>"} might have
|
1611
|
809 |
|
|
810 |
\begin{center}
|
1637
|
811 |
@{text "C\<^sup>\<alpha> label\<^isub>1::ty"}$'_1$ @{text "\<dots> label\<^isub>l::ty"}$'_l\;\;$ @{text "binding_clauses"}
|
1611
|
812 |
\end{center}
|
1587
|
813 |
|
1611
|
814 |
\noindent
|
1637
|
815 |
whereby some of the @{text ty}$'_{1..l}$ (or their components) are contained in the collection
|
|
816 |
of @{text ty}$^\alpha_{1..n}$ declared in \eqref{scheme}. In this case we will call the
|
1636
|
817 |
corresponding argument a \emph{recursive argument}. The labels annotated on
|
|
818 |
the types are optional and can be used in the (possibly empty) list of
|
1637
|
819 |
\emph{binding clauses}. These clauses indicate the binders and their scope of
|
|
820 |
in a term-constructor. They come in three \emph{modes}:
|
1636
|
821 |
|
1587
|
822 |
|
1611
|
823 |
\begin{center}
|
1617
|
824 |
\begin{tabular}{l}
|
|
825 |
\isacommand{bind}\; {\it binders}\; \isacommand{in}\; {\it label}\\
|
|
826 |
\isacommand{bind\_set}\; {\it binders}\; \isacommand{in}\; {\it label}\\
|
|
827 |
\isacommand{bind\_res}\; {\it binders}\; \isacommand{in}\; {\it label}\\
|
|
828 |
\end{tabular}
|
1611
|
829 |
\end{center}
|
|
830 |
|
|
831 |
\noindent
|
1636
|
832 |
The first mode is for binding lists of atoms (the order of binders matters); the second is for sets
|
1637
|
833 |
of binders (the order does not matter, but the cardinality does) and the last is for
|
1620
|
834 |
sets of binders (with vacuous binders preserving alpha-equivalence).
|
|
835 |
|
|
836 |
In addition we distinguish between \emph{shallow} binders and \emph{deep}
|
|
837 |
binders. Shallow binders are of the form \isacommand{bind}\; {\it label}\;
|
1637
|
838 |
\isacommand{in}\; {\it label'} (similar for the other two modes). The
|
1620
|
839 |
restriction we impose on shallow binders is that the {\it label} must either
|
|
840 |
refer to a type that is an atom type or to a type that is a finite set or
|
1637
|
841 |
list of an atom type. Two examples for the use of shallow binders are the
|
|
842 |
specification of lambda-terms, where a single name is bound, and of
|
|
843 |
type-schemes, where a finite set of names is bound:
|
1611
|
844 |
|
|
845 |
\begin{center}
|
1612
|
846 |
\begin{tabular}{@ {}cc@ {}}
|
|
847 |
\begin{tabular}{@ {}l@ {\hspace{-1mm}}}
|
|
848 |
\isacommand{nominal\_datatype} {\it lam} =\\
|
|
849 |
\hspace{5mm}\phantom{$\mid$} Var\;{\it name}\\
|
|
850 |
\hspace{5mm}$\mid$ App\;{\it lam}\;{\it lam}\\
|
|
851 |
\hspace{5mm}$\mid$ Lam\;{\it x::name}\;{\it t::lam}\\
|
1617
|
852 |
\hspace{21mm}\isacommand{bind} {\it x} \isacommand{in} {\it t}\\
|
1611
|
853 |
\end{tabular} &
|
1612
|
854 |
\begin{tabular}{@ {}l@ {}}
|
|
855 |
\isacommand{nominal\_datatype} {\it ty} =\\
|
|
856 |
\hspace{5mm}\phantom{$\mid$} TVar\;{\it name}\\
|
|
857 |
\hspace{5mm}$\mid$ TFun\;{\it ty}\;{\it ty}\\
|
1617
|
858 |
\isacommand{and} {\it tsc} = All\;{\it xs::(name fset)}\;{\it T::ty}\\
|
1619
|
859 |
\hspace{24mm}\isacommand{bind\_res} {\it xs} \isacommand{in} {\it T}\\
|
1611
|
860 |
\end{tabular}
|
|
861 |
\end{tabular}
|
|
862 |
\end{center}
|
1587
|
863 |
|
1612
|
864 |
\noindent
|
1637
|
865 |
Note that in this specification \emph{name} refers to an atom type.
|
1628
|
866 |
If we have shallow binders that ``share'' a body, for instance $t$ in
|
1637
|
867 |
the following term-constructor
|
1620
|
868 |
|
|
869 |
\begin{center}
|
|
870 |
\begin{tabular}{ll}
|
1637
|
871 |
\it {\rm Foo} x::name y::name t::lam & \it
|
1620
|
872 |
\isacommand{bind}\;x\;\isacommand{in}\;t,\;
|
|
873 |
\isacommand{bind}\;y\;\isacommand{in}\;t
|
|
874 |
\end{tabular}
|
|
875 |
\end{center}
|
|
876 |
|
|
877 |
\noindent
|
1628
|
878 |
then we have to make sure the modes of the binders agree. We cannot
|
1637
|
879 |
have, for instance, in the first binding clause the mode \isacommand{bind}
|
|
880 |
and in the second \isacommand{bind\_set}.
|
1620
|
881 |
|
|
882 |
A \emph{deep} binder uses an auxiliary binding function that ``picks'' out
|
1636
|
883 |
the atoms in one argument of the term-constructor, which can be bound in
|
1628
|
884 |
other arguments and also in the same argument (we will
|
1637
|
885 |
call such binders \emph{recursive}, see below).
|
1620
|
886 |
The binding functions are expected to return either a set of atoms
|
|
887 |
(for \isacommand{bind\_set} and \isacommand{bind\_res}) or a list of atoms
|
|
888 |
(for \isacommand{bind}). They can be defined by primitive recursion over the
|
|
889 |
corresponding type; the equations must be given in the binding function part of
|
1628
|
890 |
the scheme shown in \eqref{scheme}. For example for a calculus containing lets
|
1637
|
891 |
with tuple patterns, you might specify
|
1617
|
892 |
|
1619
|
893 |
\begin{center}
|
|
894 |
\begin{tabular}{l}
|
|
895 |
\isacommand{nominal\_datatype} {\it trm} =\\
|
|
896 |
\hspace{5mm}\phantom{$\mid$} Var\;{\it name}\\
|
|
897 |
\hspace{5mm}$\mid$ App\;{\it trm}\;{\it trm}\\
|
|
898 |
\hspace{5mm}$\mid$ Lam\;{\it x::name}\;{\it t::trm}
|
|
899 |
\;\;\isacommand{bind} {\it x} \isacommand{in} {\it t}\\
|
|
900 |
\hspace{5mm}$\mid$ Let\;{\it p::pat}\;{\it trm}\; {\it t::trm}
|
1636
|
901 |
\;\;\isacommand{bind} {\it bn(p)} \isacommand{in} {\it t}\\
|
1619
|
902 |
\isacommand{and} {\it pat} =\\
|
1637
|
903 |
\hspace{5mm}\phantom{$\mid$} PNil\\
|
|
904 |
\hspace{5mm}$\mid$ PVar\;{\it name}\\
|
|
905 |
\hspace{5mm}$\mid$ PTup\;{\it pat}\;{\it pat}\\
|
1636
|
906 |
\isacommand{with} {\it bn::pat $\Rightarrow$ atom list}\\
|
1637
|
907 |
\isacommand{where} $\textit{bn}(\textrm{PNil}) = []$\\
|
|
908 |
\hspace{5mm}$\mid$ $\textit{bn}(\textrm{PVar}\;x) = [\textit{atom}\; x]$\\
|
|
909 |
\hspace{5mm}$\mid$ $\textit{bn}(\textrm{PTup}\;p_1\;p_2) = \textit{bn}(p_1)\; @\;\textit{bn}(p_2)$\\
|
1619
|
910 |
\end{tabular}
|
|
911 |
\end{center}
|
1617
|
912 |
|
1619
|
913 |
\noindent
|
1637
|
914 |
In this specification the function @{text "bn"} determines which atoms of @{text p} are
|
|
915 |
bound in the argument @{text "t"}. Note that the second last clause the function @{text "atom"}
|
|
916 |
coerces a name into the generic atom type of Nominal Isabelle. This allows
|
|
917 |
us to treat binders of different atom type uniformly.
|
|
918 |
|
|
919 |
As will shortly become clear, we cannot return an atom in a binding function
|
|
920 |
that is also bound in the corresponding term-constructor. That means in the
|
|
921 |
example above that the term-constructors PVar and PTup must not have a
|
|
922 |
binding clause. In the present version of Nominal Isabelle, we also adopted
|
|
923 |
the restriction from the Ott-tool that binding functions can only return:
|
|
924 |
the empty set or empty list (as in case PNil), a singleton set or singleton
|
|
925 |
list containing an atom (case PVar), or unions of atom sets or appended atom
|
|
926 |
lists (case PTup). This restriction will simplify proofs later on.
|
|
927 |
The the most drastic restriction we have to impose on deep binders is that
|
|
928 |
we cannot have ``overlapping'' deep binders. Consider for example the
|
|
929 |
term-constructors:
|
1617
|
930 |
|
1620
|
931 |
\begin{center}
|
|
932 |
\begin{tabular}{ll}
|
1637
|
933 |
\it {\rm Foo} p::pat q::pat t::trm & \it \isacommand{bind}\;bn(p)\;\isacommand{in}\;t,\;
|
1620
|
934 |
\isacommand{bind}\;bn(q)\;\isacommand{in}\;t\\
|
1637
|
935 |
\it {\rm Foo}$'$x::name p::pat t::trm & \it \it \isacommand{bind}\;x\;\isacommand{in}\;t,\;
|
1620
|
936 |
\isacommand{bind}\;bn(p)\;\isacommand{in}\;t
|
|
937 |
|
|
938 |
\end{tabular}
|
|
939 |
\end{center}
|
|
940 |
|
|
941 |
\noindent
|
1637
|
942 |
In the first case we bind all atoms from the pattern @{text p} in @{text t}
|
|
943 |
and also all atoms from @{text q} in @{text t}. As a result we have no way
|
|
944 |
to determine whether the binder came from the binding function @{text
|
|
945 |
"bn(p)"} or @{text "bn(q)"}. Similarly in the second case. There the binder
|
|
946 |
@{text "bn(p)"} overlaps with the shallow binder @{text x}. The reason why
|
1693
|
947 |
we must exclude such specifications is that they cannot be represent by
|
1637
|
948 |
the general binders described in Section \ref{sec:binders}. However
|
|
949 |
the following two term-constructors are allowed
|
1620
|
950 |
|
|
951 |
\begin{center}
|
|
952 |
\begin{tabular}{ll}
|
1637
|
953 |
\it {\rm Bar} p::pat t::trm s::trm & \it \isacommand{bind}\;bn(p)\;\isacommand{in}\;t,\;
|
1620
|
954 |
\isacommand{bind}\;bn(p)\;\isacommand{in}\;s\\
|
1637
|
955 |
\it {\rm Bar}$'$p::pat t::trm & \it \isacommand{bind}\;bn(p)\;\isacommand{in}\;p,\;
|
1620
|
956 |
\isacommand{bind}\;bn(p)\;\isacommand{in}\;t\\
|
|
957 |
\end{tabular}
|
|
958 |
\end{center}
|
|
959 |
|
|
960 |
\noindent
|
1628
|
961 |
since there is no overlap of binders.
|
1619
|
962 |
|
1637
|
963 |
Note that in the last example we wrote {\it\isacommand{bind}\;bn(p)\;\isacommand{in}\;p}.
|
1693
|
964 |
Whenever such a binding clause is present, we will call the binder \emph{recursive}.
|
1637
|
965 |
To see the purpose for this, consider ``plain'' Lets and Let\_recs:
|
1636
|
966 |
|
|
967 |
\begin{center}
|
1637
|
968 |
\begin{tabular}{@ {}l@ {}}
|
1636
|
969 |
\isacommand{nominal\_datatype} {\it trm} =\\
|
|
970 |
\hspace{5mm}\phantom{$\mid$}\ldots\\
|
|
971 |
\hspace{5mm}$\mid$ Let\;{\it a::assn}\; {\it t::trm}
|
|
972 |
\;\;\isacommand{bind} {\it bn(a)} \isacommand{in} {\it t}\\
|
1637
|
973 |
\hspace{5mm}$\mid$ Let\_rec\;{\it a::assn}\; {\it t::trm}
|
|
974 |
\;\;\isacommand{bind} {\it bn(a)} \isacommand{in} {\it t},
|
|
975 |
\isacommand{bind} {\it bn(a)} \isacommand{in} {\it a}\\
|
1636
|
976 |
\isacommand{and} {\it assn} =\\
|
|
977 |
\hspace{5mm}\phantom{$\mid$} ANil\\
|
|
978 |
\hspace{5mm}$\mid$ ACons\;{\it name}\;{\it trm}\;{\it assn}\\
|
|
979 |
\isacommand{with} {\it bn::assn $\Rightarrow$ atom list}\\
|
|
980 |
\isacommand{where} $bn(\textrm{ANil}) = []$\\
|
|
981 |
\hspace{5mm}$\mid$ $bn(\textrm{ACons}\;x\;t\;a) = [atom\; x]\; @\; bn(a)$\\
|
|
982 |
\end{tabular}
|
|
983 |
\end{center}
|
|
984 |
|
|
985 |
\noindent
|
1637
|
986 |
The difference is that with Let we only want to bind the atoms @{text
|
|
987 |
"bn(a)"} in the term @{text t}, but with Let\_rec we also want to bind the atoms
|
|
988 |
inside the assignment. This requires recursive binders and also has
|
|
989 |
consequences for the free variable function and alpha-equivalence relation,
|
|
990 |
which we are going to explain in the rest of this section.
|
|
991 |
|
|
992 |
Having dealt with all syntax matters, the problem now is how we can turn
|
|
993 |
specifications into actual type definitions in Isabelle/HOL and then
|
|
994 |
establish a reasoning infrastructure for them. Because of the problem
|
|
995 |
Pottier and Cheney pointed out, we cannot in general re-arrange arguments of
|
|
996 |
term-constructors so that binders and their bodies are next to each other, and
|
|
997 |
then use the type constructors @{text "abs_set"}, @{text "abs_res"} and
|
|
998 |
@{text "abs_list"} from Section \ref{sec:binders}. Therefore we will first
|
|
999 |
extract datatype definitions from the specification and then define an
|
1693
|
1000 |
alpha-equivalence relation over them.
|
1637
|
1001 |
|
|
1002 |
|
|
1003 |
The datatype definition can be obtained by just stripping off the
|
|
1004 |
binding clauses and the labels on the types. We also have to invent
|
|
1005 |
new names for the types @{text "ty\<^sup>\<alpha>"} and term-constructors @{text "C\<^sup>\<alpha>"}
|
|
1006 |
given by user. In our implementation we just use an affix like
|
1636
|
1007 |
|
|
1008 |
\begin{center}
|
1637
|
1009 |
@{text "ty\<^sup>\<alpha> \<mapsto> ty_raw"} \hspace{7mm} @{text "C\<^sup>\<alpha> \<mapsto> C_raw"}
|
1636
|
1010 |
\end{center}
|
|
1011 |
|
|
1012 |
\noindent
|
1637
|
1013 |
The resulting datatype definition is legal in Isabelle/HOL provided the datatypes are
|
|
1014 |
non-empty and the types in the constructors only occur in positive
|
1693
|
1015 |
position (see \cite{} for an indepth explanation of the datatype package
|
1637
|
1016 |
in Isabelle/HOL). We then define the user-specified binding
|
|
1017 |
functions by primitive recursion over the raw datatypes. We can also
|
|
1018 |
easily define a permutation operation by primitive recursion so that for each
|
|
1019 |
term constructor @{text "C_raw ty\<^isub>1 \<dots> ty\<^isub>n"} we have that
|
1587
|
1020 |
|
1628
|
1021 |
\begin{center}
|
1637
|
1022 |
@{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
|
1023 |
\end{center}
|
|
1024 |
|
|
1025 |
\noindent
|
1637
|
1026 |
From this definition we can easily show that the raw datatypes are
|
|
1027 |
all permutation types (Def ??) by a simple structural induction over
|
|
1028 |
the @{text "ty_raw"}s.
|
|
1029 |
|
1693
|
1030 |
The first non-trivial step we have to perform is the generation free-variable
|
1637
|
1031 |
functions from the specifications. Given types @{text "ty\<^isub>1, \<dots>, ty\<^isub>n"}
|
|
1032 |
we need to define the free-variable functions
|
|
1033 |
|
|
1034 |
\begin{center}
|
|
1035 |
@{text "fv_ty\<^isub>1 :: ty\<^isub>1 \<Rightarrow> atom set \<dots> fv_ty\<^isub>n :: ty\<^isub>n \<Rightarrow> atom set"}
|
|
1036 |
\end{center}
|
|
1037 |
|
|
1038 |
\noindent
|
|
1039 |
and given binding functions @{text "bn_ty\<^isub>1, \<dots>, bn_ty\<^isub>m"} we also need to define
|
|
1040 |
the free-variable functions
|
1628
|
1041 |
|
1637
|
1042 |
\begin{center}
|
|
1043 |
@{text "fv_bn_ty\<^isub>1 :: ty\<^isub>1 \<Rightarrow> atom set \<dots> fv_bn_ty\<^isub>m :: ty\<^isub>m \<Rightarrow> atom set"}
|
|
1044 |
\end{center}
|
1636
|
1045 |
|
1637
|
1046 |
\noindent
|
|
1047 |
The basic idea behind these free-variable functions is to collect all atoms
|
|
1048 |
that are not bound in a term constructor, but because of the rather
|
|
1049 |
complicated binding mechanisms the details are somewhat involved.
|
|
1050 |
|
|
1051 |
Given a term-constructor @{text "C_raw ty\<^isub>1 \<dots> ty\<^isub>n"}, of type @{text ty} together with
|
|
1052 |
some binding clauses, the function @{text "fv_ty (C_raw x\<^isub>1 \<dots> x\<^isub>n)"} will be
|
|
1053 |
the union of the values defined below for each argument, say @{text "x\<^isub>i"} with type @{text "ty\<^isub>i"}.
|
|
1054 |
From the binding clause of this term constructor, we can determine whether the
|
|
1055 |
argument @{text "x\<^isub>i"} is a shallow or deep binder, and in the latter case also
|
|
1056 |
whether it is a recursive or non-recursive of a binder. In these cases the value is:
|
1628
|
1057 |
|
|
1058 |
\begin{center}
|
1636
|
1059 |
\begin{tabular}{cp{7cm}}
|
|
1060 |
$\bullet$ & @{term "{}"} provided @{text "x\<^isub>i"} is a shallow binder\\
|
1693
|
1061 |
$\bullet$ & @{text "ft_bn_by\<^isub>i x\<^isub>i"} provided @{text "x\<^isub>i"} is a deep non-recursive binder\\
|
1636
|
1062 |
$\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
|
1063 |
\end{tabular}
|
|
1064 |
\end{center}
|
|
1065 |
|
1636
|
1066 |
\noindent
|
1637
|
1067 |
In case the argument @{text "x\<^isub>i"} is not a binder, it might be a body of
|
|
1068 |
one or more abstractions. There are two cases: either the
|
1636
|
1069 |
corresponding binders are all shallow or there is a single deep binder.
|
|
1070 |
In the former case we build the union of all shallow binders; in the
|
|
1071 |
later case we just take set or list of atoms the specified binding
|
1637
|
1072 |
function returns. Let @{text "bnds"} be an abbreviation of the bound
|
|
1073 |
atoms. Then the value is given by:
|
1636
|
1074 |
|
|
1075 |
\begin{center}
|
|
1076 |
\begin{tabular}{cp{7cm}}
|
|
1077 |
$\bullet$ & @{text "{atom x\<^isub>i} - bnds"} provided @{term "x\<^isub>i"} is an atom\\
|
|
1078 |
$\bullet$ & @{text "(atoms x\<^isub>i) - bnds"} provided @{term "x\<^isub>i"} is a set of atoms\\
|
1657
|
1079 |
$\bullet$ & @{text "(atoms (set x\<^isub>i)) - bnds"} provided @{term "x\<^isub>i"} is a list of atoms\\
|
1636
|
1080 |
$\bullet$ & @{text "(fv_ty\<^isub>i x\<^isub>i) - bnds"} provided @{term "ty\<^isub>i"} is a nominal datatype\\
|
|
1081 |
$\bullet$ & @{term "{}"} otherwise
|
|
1082 |
\end{tabular}
|
|
1083 |
\end{center}
|
1628
|
1084 |
|
1636
|
1085 |
\noindent
|
1637
|
1086 |
If the argument is neither a binder, nor a body of an abstraction, then the
|
|
1087 |
value is defined as above, except that @{text "bnds"} is empty. i.e.~no atoms
|
1636
|
1088 |
are abstracted.
|
1628
|
1089 |
|
1637
|
1090 |
TODO
|
|
1091 |
|
|
1092 |
Given a clause of a binding function of the form
|
|
1093 |
|
|
1094 |
\begin{center}
|
|
1095 |
@{text "bn_ty (C_raw x\<^isub>1 \<dots> x\<^isub>n) = rhs"}
|
|
1096 |
\end{center}
|
|
1097 |
|
|
1098 |
\noindent
|
|
1099 |
then the corresponding free-variable function @{text "fv_bn_ty\<^isub>i"} is the
|
|
1100 |
union of the values calculated for the @{text "x\<^isub>j"} as follows:
|
|
1101 |
|
|
1102 |
\begin{center}
|
|
1103 |
\begin{tabular}{cp{7cm}}
|
|
1104 |
$\bullet$ & @{text "{}"} provided @{term "x\<^isub>j"} occurs in @{text "rhs"} and is an atom\\
|
|
1105 |
$\bullet$ & @{text "fv_bn_ty x\<^isub>j"} provided @{term "x\<^isub>j"} occurs in @{text "rhs"}
|
|
1106 |
with the recursive call @{text "bn_ty x\<^isub>j"}\\
|
|
1107 |
$\bullet$ & @{text "(atoms x\<^isub>i) - bnds"} provided @{term "x\<^isub>i"} is a set of atoms\\
|
|
1108 |
$\bullet$ & @{text "(atoml x\<^isub>i) - bnds"} provided @{term "x\<^isub>i"} is a list of atoms\\
|
|
1109 |
$\bullet$ & @{text "(fv_ty\<^isub>i x\<^isub>i) - bnds"} provided @{term "ty\<^isub>i"} is a nominal datatype\\
|
|
1110 |
$\bullet$ & @{term "{}"} otherwise
|
|
1111 |
\end{tabular}
|
|
1112 |
\end{center}
|
|
1113 |
|
1587
|
1114 |
*}
|
|
1115 |
|
1637
|
1116 |
section {* The Lifting of Definitions and Properties *}
|
1587
|
1117 |
|
|
1118 |
text {*
|
1520
|
1119 |
Restrictions
|
|
1120 |
|
|
1121 |
\begin{itemize}
|
1572
|
1122 |
\item non-emptiness
|
1520
|
1123 |
\item positive datatype definitions
|
|
1124 |
\item finitely supported abstractions
|
|
1125 |
\item respectfulness of the bn-functions\bigskip
|
|
1126 |
\item binders can only have a ``single scope''
|
1577
|
1127 |
\item all bindings must have the same mode
|
1520
|
1128 |
\end{itemize}
|
|
1129 |
*}
|
|
1130 |
|
1493
|
1131 |
section {* Examples *}
|
1485
|
1132 |
|
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
|
1133 |
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
|
1134 |
|
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
|
1135 |
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
|
1136 |
|
1570
|
1137 |
text {*
|
|
1138 |
Ott is better with list dot specifications; subgrammars
|
|
1139 |
|
|
1140 |
untyped;
|
|
1141 |
|
|
1142 |
*}
|
|
1143 |
|
|
1144 |
|
1493
|
1145 |
section {* Conclusion *}
|
1485
|
1146 |
|
|
1147 |
text {*
|
1520
|
1148 |
Complication when the single scopedness restriction is lifted (two
|
|
1149 |
overlapping permutations)
|
1662
|
1150 |
|
|
1151 |
|
|
1152 |
The formalisation presented here will eventually become part of the
|
|
1153 |
Isabelle distribution, but for the moment it can be downloaded from
|
|
1154 |
the Mercurial repository linked at
|
|
1155 |
\href{http://isabelle.in.tum.de/nominal/download}
|
|
1156 |
{http://isabelle.in.tum.de/nominal/download}.\medskip
|
1520
|
1157 |
*}
|
|
1158 |
|
|
1159 |
text {*
|
1493
|
1160 |
|
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
|
1161 |
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
|
1162 |
\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
|
1163 |
|
1493
|
1164 |
\noindent
|
1528
|
1165 |
{\bf Acknowledgements:} We are very grateful to Andrew Pitts for
|
1506
|
1166 |
many discussions about Nominal Isabelle. We thank Peter Sewell for
|
|
1167 |
making the informal notes \cite{SewellBestiary} available to us and
|
1556
|
1168 |
also for patiently explaining some of the finer points about the abstract
|
1545
|
1169 |
definitions and about the implementation of the Ott-tool.
|
1485
|
1170 |
|
1577
|
1171 |
Lookup: Merlin paper by James Cheney; Mark Shinwell PhD
|
754
|
1172 |
|
1577
|
1173 |
Future work: distinct list abstraction
|
|
1174 |
|
|
1175 |
|
754
|
1176 |
*}
|
|
1177 |
|
1484
|
1178 |
|
|
1179 |
|
754
|
1180 |
(*<*)
|
|
1181 |
end
|
|
1182 |
(*>*) |