|
16233
|
1 |
<?xml version='1.0' encoding='iso-8859-1' ?>
|
|
|
2 |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
16240
|
3 |
<!-- $Id$ -->
|
|
16233
|
4 |
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
|
5 |
|
|
|
6 |
<head>
|
|
|
7 |
<title>Isabelle FAQ</title>
|
|
|
8 |
<?include file="//include/htmlheader.include.html"?>
|
|
|
9 |
</head>
|
|
|
10 |
|
|
|
11 |
<body class="main">
|
|
|
12 |
<?include file="//include/header.include.html"?>
|
|
|
13 |
<div class="hr"><hr/></div>
|
|
|
14 |
<?include file="//include/navigation.include.html"?>
|
|
|
15 |
<div class="hr"><hr/></div>
|
|
|
16 |
<div id="content">
|
|
|
17 |
|
|
|
18 |
<h2>General Questions</h2>
|
|
|
19 |
|
|
|
20 |
<dl class="faq">
|
|
|
21 |
|
|
|
22 |
<dt>What is Isabelle?</dt>
|
|
|
23 |
|
|
|
24 |
<dd>Isabelle is a popular generic theorem proving environment developed
|
|
|
25 |
at Cambridge University (<a href=
|
|
|
26 |
"http://www.cl.cam.ac.uk/users/lcp/">Larry Paulson</a>) and TU Munich
|
|
|
27 |
(<a href="http://www.in.tum.de/~nipkow/">Tobias Nipkow</a>). See the
|
|
|
28 |
<a href="http://isabelle.in.tum.de/">Isabelle homepage</a> for more
|
|
|
29 |
information.</dd>
|
|
|
30 |
|
|
|
31 |
<dt>Where can I find documentation?</dt>
|
|
|
32 |
|
|
|
33 |
<dd><a href="http://isabelle.in.tum.de/docs.html">This way, please</a>.
|
|
|
34 |
Also have a look at the <a href=
|
|
|
35 |
"http://isabelle.in.tum.de/library/">theory library</a>.</dd>
|
|
|
36 |
|
|
|
37 |
<dt>Is it available for download?</dt>
|
|
|
38 |
|
|
|
39 |
<dd>Yes, it is available from <a href=
|
|
|
40 |
"http://isabelle.in.tum.de/dist/">several mirror sites</a>. It should run
|
|
|
41 |
on most recent Unix systems (Solaris, Linux, MacOS X, etc.).</dd>
|
|
|
42 |
|
|
|
43 |
</dl>
|
|
|
44 |
<h2>Syntax</h2>
|
|
|
45 |
|
|
|
46 |
<dl class="faq">
|
|
|
47 |
|
|
|
48 |
<dt>There are lots of arrows in Isabelle. What's the difference between
|
|
|
49 |
<tt>-></tt>, <tt>=></tt>, <tt>--></tt>, and <tt>==></tt>
|
|
|
50 |
?</dt>
|
|
|
51 |
|
|
|
52 |
<dd>Isabelle uses the <tt>=></tt> arrow for the function type
|
|
|
53 |
(contrary to most functional languages which use <tt>-></tt>). So
|
|
|
54 |
<tt>a => b</tt> is the type of a function that takes an element of
|
|
|
55 |
<tt>a</tt> as input and gives you an element of <tt>b</tt> as output. The
|
|
|
56 |
long arrow <tt>--></tt> and <tt>==></tt> are object and meta level
|
|
|
57 |
implication. Roughly speaking, the meta level implication should only be
|
|
|
58 |
used when stating theorems where it separates the assumptions from the
|
|
|
59 |
conclusion. Whenever you need an implication inside a HOL formula, use
|
|
|
60 |
<code>--></code>.</dd>
|
|
|
61 |
|
|
|
62 |
<dt>Where do I have to put those double quotes?</dt>
|
|
|
63 |
|
|
|
64 |
<dd>Isabelle distinguishes between <em>inner</em> and <em>outer</em>
|
|
|
65 |
syntax. The outer syntax comes from the Isabelle framework, the inner
|
|
|
66 |
syntax is the one in between quotation marks and comes from the object
|
|
|
67 |
logic (in this case HOL). With time the distinction between the two
|
|
|
68 |
becomes obvious, but in the beginning the following rules of thumb may
|
|
|
69 |
work: types should be inside quotation marks, formulas and lemmas should
|
|
|
70 |
be inside quotation marks, rules and equations (e.g. for definitions)
|
|
|
71 |
should be inside quotation marks, commands like <tt>lemma</tt>,
|
|
|
72 |
<tt>consts</tt>, <tt>primrec</tt>, <tt>constdefs</tt>, <tt>apply</tt>,
|
|
|
73 |
<tt>done</tt> are without quotation marks, as are the names of constants
|
|
|
74 |
in constant definitions (<tt>consts</tt> and <tt>constdefs</tt>)</dd>
|
|
|
75 |
|
|
|
76 |
<dt>What is <tt>"No such constant: _case_syntax"</tt> supposed to tell
|
|
|
77 |
me?</dt>
|
|
|
78 |
|
|
|
79 |
<dd>You get this message if you use a case construct on a datatype and
|
|
|
80 |
have a typo in the names of the constructor patterns or if the order of
|
|
|
81 |
the constructors in the case pattern is different from the order in which
|
|
|
82 |
they where defined (in the datatype definition).</dd>
|
|
|
83 |
|
|
|
84 |
<dt>Why doesn't Isabelle understand my equation?</dt>
|
|
|
85 |
|
|
|
86 |
<dd>Isabelle's equality <tt>=</tt> binds relatively strongly, so an
|
|
|
87 |
equation like <tt>a = b & c</tt> might not be what you intend.
|
|
|
88 |
Isabelle parses it as <tt>(a = b) & c</tt>. If you want it the other
|
|
|
89 |
way around, you must set explicit parentheses as in <tt>a = (b &
|
|
|
90 |
c)</tt>. This also applies to e.g. <tt>primrec</tt> definitions (see
|
|
|
91 |
below).</dd>
|
|
|
92 |
|
|
|
93 |
<dt>What does it mean "not a proper equation"?</dt>
|
|
|
94 |
|
|
|
95 |
<dd>Most commonly this is an instance of the question above. The
|
|
|
96 |
<tt>primrec</tt> command (and others) expect equations as input, and
|
|
|
97 |
since equality binds strongly in Isabelle, something like <tt>f x = b
|
|
|
98 |
& c</tt> is not what you might expect it to be: Isabelle parses it as
|
|
|
99 |
<tt>(f x = b) & c</tt> (which is indeed not a proper equation). To
|
|
|
100 |
turn it into an equation you must set explicit parentheses: <tt>f x = (b
|
|
|
101 |
& c)</tt>.</dd>
|
|
|
102 |
|
|
|
103 |
<dt>What does it mean "<tt>Not a meta-equality (==)</tt>"?</dt>
|
|
|
104 |
|
|
|
105 |
<dd>This usually occurs if you use <tt>=</tt> for <tt>constdefs</tt>. The
|
|
|
106 |
<tt>constdefs</tt> and <tt>defs</tt> commands expect not equations, but
|
|
|
107 |
meta equivalences. Just use the <tt>\<equiv></tt> or <tt>==</tt>
|
|
|
108 |
signs instead of <tt>=</tt>.</dd>
|
|
|
109 |
|
|
|
110 |
</dl>
|
|
|
111 |
<h2>Proving</h2>
|
|
|
112 |
|
|
|
113 |
<dl class="faq">
|
|
|
114 |
|
|
|
115 |
<dt>What does "empty result sequence" mean?</dt>
|
|
|
116 |
|
|
|
117 |
<dd>It means that the applied proof method (or tactic) was unsuccessful.
|
|
|
118 |
It did not transform the goal in any way, or simply just failed to do
|
|
|
119 |
anything. You must try another tactic (or give the one you used more
|
|
|
120 |
hints or lemmas to work with)</dd>
|
|
|
121 |
|
|
|
122 |
<dt>The Simplifier doesn't want to apply my rule, what's wrong?</dt>
|
|
|
123 |
|
|
|
124 |
<dd>Most commonly this is a typing problem. The rule you want to apply
|
|
|
125 |
may require a more special (or just plain different) type from what you
|
|
|
126 |
have in the current goal. Use the ProofGeneral menu <tt>Isabelle/Isar
|
|
|
127 |
-> Settings -> Show Types</tt> and the <tt>thm</tt> command on the
|
|
|
128 |
rule you want to apply to find out if the types are what you expect them
|
|
|
129 |
to be (also take a look at the types in your goal). <tt>Show Sorts</tt>,
|
|
|
130 |
<tt>Show Constants</tt>, and <tt>Trace Simplifier</tt> in the same menu
|
|
|
131 |
may also be helpful.</dd>
|
|
|
132 |
|
|
|
133 |
<dt>If I do <tt>auto</tt>, it leaves me a goal <tt>False</tt>. Is my
|
|
|
134 |
theorem wrong?</dt>
|
|
|
135 |
|
|
|
136 |
<dd>Not necessarily. It just means that <tt>auto</tt> transformed the
|
|
|
137 |
goal into something that is not provable any more. That could be due to
|
|
|
138 |
<tt>auto</tt> doing something stupid, or e.g. due to some earlier step in
|
|
|
139 |
the proof that lost important information. It is of course also possible
|
|
|
140 |
that the goal was never provable in the first place.</dd>
|
|
|
141 |
|
|
|
142 |
<dt>Why does <tt>lemma "1+1=2"</tt> fail?</dt>
|
|
|
143 |
|
|
|
144 |
<dd>Because it is not necessarily true. Isabelle does not assume that 1
|
|
|
145 |
and 2 are natural numbers. Try <tt>"(1::nat)+1=2"</tt> instead.</dd>
|
|
|
146 |
|
|
|
147 |
<dt>Can Isabelle find counterexamples?</dt>
|
|
|
148 |
|
|
|
149 |
<dd>
|
|
|
150 |
<p>For arithmetic goals, <code>arith</code> finds counterexamples. For
|
|
|
151 |
executable goals, <code>quickcheck</code> tries to find a
|
|
|
152 |
counterexample. For goals of a more logical nature (including
|
|
|
153 |
quantifiers, sets and inductive definitions) <code>refute</code>
|
|
|
154 |
searches for a countermodel.</p>
|
|
|
155 |
|
|
|
156 |
<p>Otherwise, negate the proposition and instantiate (some) variables
|
|
|
157 |
with concrete values. You may also need additional assumptions about
|
|
|
158 |
these values. For example, <tt>True & False ~= True | False</tt> is
|
|
|
159 |
a counterexample of <tt>A & B = A | B</tt>, and <tt>A = ~B ==> A
|
|
|
160 |
& B ~= A | B</tt> is another one. Sometimes Isabelle can help you
|
|
|
161 |
to find the counterexample: just negate the proposition and do
|
|
|
162 |
<tt>auto</tt> or <tt>simp</tt>. If lucky, you are left with the
|
|
|
163 |
assumptions you need for the counterexample to work.</p>
|
|
|
164 |
</dd>
|
|
|
165 |
|
|
|
166 |
</dl>
|
|
|
167 |
<h2>Interface</h2>
|
|
|
168 |
|
|
|
169 |
<dl class="faq">
|
|
|
170 |
|
|
|
171 |
<dt>ProofGeneral appears to hang when Isabelle is started.</dt>
|
|
|
172 |
<dd><p>This may be because of UTF-8 issues e.g. in Red Hat 8.0/9.0, Suse
|
|
|
173 |
9.0/9.1</p>
|
|
|
174 |
<p>RedHat 8 and later has glibc 2.2 and UTF8 encoded output may be turned on
|
|
|
175 |
in default locale. Unfortunately Proof General relies on 8-bit characters
|
|
|
176 |
which are UTF8 prefixes in the output of proof assistants (inc Coq,
|
|
|
177 |
Isabelle). These prefix characters are not flushed to stdout individually. As
|
|
|
178 |
a workaround we must find a way to disable interpretation of UTF8 in the C
|
|
|
179 |
libraries that Coq and friends use.</p>
|
|
|
180 |
|
|
|
181 |
<p>Doing this inside PG/Emacs seems tricky; locale settings are set/inherited
|
|
|
182 |
in strange ways. One solution is to run the Emacs process itself with an
|
|
|
183 |
altered locale setting, for example, starting XEmacs by typing:</p>
|
|
|
184 |
|
|
16240
|
185 |
<ul class="shellcmd">
|
|
|
186 |
<li>LC_CTYPE=en_GB Isabelle &</li>
|
|
|
187 |
</ul>
|
|
16233
|
188 |
|
|
|
189 |
<p>The supplied proofgeneral script makes this setting if it sees the string
|
|
16240
|
190 |
UTF in the current value of <tt class="shellcmd">LC_CTYPE</tt>.
|
|
|
191 |
Depending on your distribution, this
|
|
|
192 |
variable might also be called <tt class="shellcmd">LANG</tt>.</p>
|
|
16233
|
193 |
|
|
16240
|
194 |
<p>Alternatively you can set <tt class="shellcmd">LC_CTYPE</tt> or
|
|
|
195 |
<tt class="shellcmd">LANG</tt> inside a file <tt class="shellcmd">~/.i18n</tt>, which
|
|
16241
|
196 |
will be read by the shell. This will affect all applications, though.</p>
|
|
16240
|
197 |
|
|
|
198 |
<p>Suggestions for a better workaround inside Emacs would be welcomed;</p>
|
|
16233
|
199 |
|
|
16240
|
200 |
<p>A related issue is warnings from x-symbol: "Emacs language environment
|
|
16233
|
201 |
and system locale specify different encoding, I'll assume `iso-8859-1'". This
|
|
|
202 |
warning appears to be mainly harmless. Notice that the variable
|
|
|
203 |
`buffer-file-coding-system' may determine the format that files are saved
|
|
|
204 |
in.</p></dd>
|
|
|
205 |
|
|
|
206 |
<dt>X-Symbol doesn't seem to work. What can I do?</dt>
|
|
|
207 |
|
|
|
208 |
<dd>The most common reason why X-Symbol doesn't work is: it's not
|
|
|
209 |
switched on yet. Assuming you are using ProofGeneral and have installed
|
|
|
210 |
the X-Symbol package, you still need to turn X-Symbol on in ProofGeneral:
|
|
|
211 |
select the menu items <tt>Proof-General -> Options -> X-Symbol</tt>
|
|
|
212 |
and (if you want to save the setting for future sessions) select
|
|
|
213 |
<tt>Options -> Save Options</tt> in XEmacs.</dd>
|
|
|
214 |
|
|
|
215 |
<dt>How do I input those X-Symbols anyway?</dt>
|
|
|
216 |
|
|
|
217 |
<dd>There are lots of ways to input x-symbols. The one that always works
|
|
|
218 |
is writing it out in plain text (e.g. for the 'and' symbol type
|
|
|
219 |
<tt>\<and></tt>). For common symbols you can try to "paint them in
|
|
|
220 |
ASCII" and if the xsymbol package recognizes them it will automatically
|
|
|
221 |
convert them into their graphical representation. Examples:
|
|
|
222 |
<tt>--></tt> is converted into the long single arrow, <tt>/\</tt> is
|
|
|
223 |
converted into the 'and' symbol, the sequence <tt>=_</tt> into the
|
|
|
224 |
equivalence sign, <tt><_</tt> into less-or-equal, <tt>[|</tt> into
|
|
|
225 |
opening semantic brackets, and so on. For greek characters, the
|
|
|
226 |
<code>rotate</code> command works well: to input α type
|
|
|
227 |
<code>a</code> and then <code>C-.</code> (control and <code>.</code>).
|
|
|
228 |
You can also display the grid-of-characters in the x-symbol menu to get
|
|
|
229 |
an overview of the available graphical representations (not all of them
|
|
|
230 |
already have a meaning in Isabelle, though).</dd>
|
|
|
231 |
|
|
|
232 |
</dl>
|
|
|
233 |
<h2>System</h2>
|
|
|
234 |
|
|
|
235 |
<dl class="faq">
|
|
|
236 |
|
|
|
237 |
<dt>I want to generate one of those flashy LaTeX documents. How?</dt>
|
|
|
238 |
|
|
16240
|
239 |
<dd>You will need to work with the <tt class="shellcmd">isatool</tt> command for this (in
|
|
16233
|
240 |
a Unix shell). The easiest way to get to a document is the following: use
|
|
16240
|
241 |
<tt class="shellcmd">isatool mkdir</tt> to set up a new directory. The command will also
|
|
|
242 |
create a file called <tt class="shellcmd">IsaMakefile</tt> in the current directory. Put
|
|
16233
|
243 |
your theory file(s) into the new directory and edit the file
|
|
16240
|
244 |
<tt class="shellcmd">ROOT.ML</tt> in there (following the comments) to tell Isabelle which
|
|
16233
|
245 |
of the theories to load (and in which order). Go back to the parent
|
|
16240
|
246 |
directory (where the <tt class="shellcmd">IsaMakefile</tt> is) and type <tt class="shellcmd">isatool
|
|
16233
|
247 |
make</tt>. Isabelle should then process your theories and tell you where
|
|
|
248 |
to find the finished document. For more information on generating
|
|
|
249 |
documents see the Isabelle Tutorial, Chapter 4.</dd>
|
|
|
250 |
|
|
|
251 |
<dt>I have a large formalization with many theories. Must I process all
|
|
|
252 |
of them all of the time?</dt>
|
|
|
253 |
|
|
|
254 |
<dd>No, you can tell Isabelle to build a so-called heap image. This heap
|
|
|
255 |
image can contain your preloaded theories. To get one, set up a directory
|
|
16240
|
256 |
with a <tt class="shellcmd">ROOT.ML</tt> file (as for generating a document) and use the
|
|
|
257 |
command <tt class="shellcmd">isatool usedir -b HOL MyImage</tt> in that directory to
|
|
|
258 |
create an image <tt class="shellcmd">MyImage</tt> using the parent logic <tt class="shellcmd">HOL</tt>. You
|
|
|
259 |
should then be able to invoke Isabelle with <tt class="shellcmd">Isabelle -l MyImage</tt>
|
|
16233
|
260 |
and have everything that is loaded in ROOT.ML instantly available.</dd>
|
|
|
261 |
|
|
|
262 |
<dt>Does Isabelle run on Windows?</dt>
|
|
|
263 |
|
|
|
264 |
<dd>After a fashion, yes, but Isabelle is not being developed for
|
|
|
265 |
Windows. See the <a href="dist/installation_notes_cygwin.html">installation notes</a> for windows.
|
|
|
266 |
If the approach presented there is not sufficient for your purpose, consider a
|
|
|
267 |
dualboot Windows/Linux system.</dd>
|
|
|
268 |
|
|
|
269 |
</dl>
|
|
|
270 |
|
|
|
271 |
</div>
|
|
|
272 |
<div class="hr"><hr/></div>
|
|
|
273 |
<?include file="//include/footer.include.html"?>
|
|
|
274 |
</body>
|
|
|
275 |
|
|
|
276 |
</html>
|