In the section 4.1.2 of the Isabelle/HOL tutorial we find
By convention, the mode of "xsymbols" is enabled whenever Proof General's X-Symbol mode or LaTeX output is active.
Now, with the fading of Proof General, is there any relevance of xsymbols?
xsymbols mode is still the default in Isabelle/jEdit.
While Isabelle/jEdit renders symbols in the editor as unicode, behind the scenes the internal representation is still using the xsymbol encoding. This can be seen by opening saved theory files up in another editor. For example, the text:
lemma "a ∧ b ⟹ b ∧ a"
by simp
is saved to a file as its xsymbols encoding:
lemma "a \<and> b \<Longrightarrow> b \<and> a"
by simp
The Isabelle plugin to jEdit performs the translation to and from unicode as it communicates with the main Isabelle process. (The translation tables can be seen in Isabelle/etc/symbols, if you are curious.)
The practical consequence of this is if your are defining notation, xsymbols refers to all of LaTeX, ProofGeneral and Isabelle/jEdit.
Perhaps in the future there will be a unicode mode, replacing the internal xsymbols representation, but we are not there yet.
Related
Can I somehow refer to the name of a lemma (or theorem or corollary) inside Isabelle text?
For example:
theory Scratch
imports Main
begin
lemma lemma_name: "stuff = stuff" by simp
text‹As we have proven in fact #{thm lemma_name}, stuff is stuff.›
end
When compiling this to pdf, I see
As we have proven in fact stuff=stuff, stuff is stuff.
I would like to see
As we have proven in fact lemma_name, stuff is stuff.
Is there some document antiqotation which just prints the name of a lemma?
I could just type the lemma name verbatim, but this neither gives me control-click in the IDE nor does it make sure the text still refers to a true fact, even if I rename lemmas.
The output of antiquotations can be changed by options explained in 4.2.1 and 4.2.2 of the Isabelle/Isar Reference Manual. One (rather hidden) option [source=true] sets the output to print what you have entered as argument to the antiquotation instead of its output.
text ‹As we have proven in fact #{thm [source] lemma_name}, stuff is stuff.
...will thus result in the document output:
As we have proven in fact lemma_name, stuff is stuff.
The checking of the validity of the reference will still take place during document preparation.
Specific example: Let's say I have demonstrated that I have a graph in the sense of https://www.isa-afp.org/theories/category3/#FreeCategory.html :
lemma i_have_a_graph: shows "graph Obj Arr Dom Cod"
sorry
where the symbols Obj, Arr, Dom, and Cod were defined earlier in the file. This gives me access to the lemmas and theorems stated within the graph locale.
How do I use the symbol path defined within the graph locale?
Related question with no answers: Access definitions from sublocale
You don't do it using a lemma but by the interpretation command:
interpretation MyGraph: graph Obj Are Dom Cod <proof>
Of course, the <proof> could use your lemma, but you don't need to prove such a lemma separately.
Now MyGraph.path refers to the path component of this instance.
See https://www.cl.cam.ac.uk/research/hvg/Isabelle/dist/Isabelle/doc/locales.pdf
Is there any known hack that allows custom syntax for definitions inside a given locale, using the syntax/translation mechanism? All of my attempts at an "obvious" solution are generating type errors, which I am led to believe is caused by syntax/translation not yet being made "locale-aware".
Raw AST transformations with syntax and translations cannot be used inside locales in Isabelle2016. There is a workaround for constants and types whose declaration does not depend on locale parameters. You merely have to issue the syntax declaration outside of the locale for the appropriate constant from background theory. Below is a proof of concept:
locale test = fixes a :: nat begin
definition foo :: "nat ⇒ nat" where "foo x = x"
end
syntax "_foo" :: "nat ⇒ bool" ("FOO")
translations "FOO" ↽ "CONST test.foo"
context test begin
term foo
This workaround does not work for constants which depend on parameters of the locale, because then constant in the background theory takes these parameters as additional arguments and the locale installs an abbreviation, which is folded before the custom syntax translation fires.
(NOTE: If I can get rid of the warning I show below, then I say a bunch of extraneous stuff. As part of asking a question, I also do some opinionating. I guess that's sort of asking the question "Why am I wrong here in what I say?")
It seems that 6 of the symbols used for bool operators should have been assigned to syntactic type classes, and bool instantiated for those type classes. In particular, these:
~, &, |, \<not>, \<and>, \<or>.
Because type annotation of terms is a frequent requirement for HOL operators, I don't think it would be a great burden to have to use bool annotations for those 6 operators.
I would like to overload those 6 symbols for other logical operators. Not having the usual symbols for an application can result in there being no good solution for notation.
In the following example source, if I can get rid of the warnings, then the problem is solved (unless I would be setting a trap for myself):
definition natOP :: "nat => nat => nat" where
"natOP x y = x"
definition natlistOP :: "nat list => nat list => nat list" where
"natlistOP x y = x"
notation
natOP (infixr "&" 35)
notation
natlistOP (infixr "&" 35)
term "True & False"
term "2 & (2::nat)"
term "[2] & [(2::nat)]" (*
OUTPUT: Ambiguous input produces 3 parse trees:
...
Fortunately, only one parse tree is well-formed and type-correct,
but you may still want to disambiguate your grammar or your input.*)
Can I get rid of the warnings? It seems that since there's a type correct term, there shouldn't be a problem.
There are actually other symbols I also want, such as !, used for list:
term "[1,2,3] ! 1"
Here's the application for which I want the symbols:
Verilog HDL Operators.
Update
Based on Brian Huffman's answer, I unnotate &, and switch & to a syntactic type class. It'll work out, or it won't, indeed, binary logic, so diversely applicable. My general rule is "don't mess with default Isabelle/HOL".
(*|Unnotate; switch to a type class; see someday why this is a bad idea.|*)
no_notation conj (infixr "&" 35)
class conj =
fixes syntactic_type_classes_are_awesome :: "'a => 'a => 'a" (infixr "&" 35)
instantiation bool :: conj
begin
definition syntactic_type_classes_are_awesome_bool :: "bool => bool => bool"
where "p & q == conj p q"
instance ..
end
term "True & False"
value "True & False"
declare[[show_sorts]]
term "p & q" (* "(p::'a::conj) & (q::'a::conj)" :: "'a::conj" *)
You can "undeclare" special syntax using the no_notation command, e.g.
no_notation conj (infixr "\<and>" 35)
This infix operator is then available to be used with your own functions:
notation myconj (infixr "\<and>" 35)
From here on, \<and> refers to the constant myconj instead of the HOL library's standard conjunction operator for type bool. You should have no warnings about ambiguous syntax. The original HOL boolean operator is still accessible by name (conj), or you can give it a different syntax if you want with another notation command.
For the no_notation command to work, the pattern and fixities must be exactly the same as they were declared originally. See src/HOL/HOL.thy for the declarations of the operators you are interested in.
I should warn about a potential pitfall: Subsequent theory merges can bring the original syntax back into scope, causing ambiguous syntax again. For example, say your theory A.thy imports Main and redeclares the \<and> syntax. Then your theory B.thy imports both A and another library theory, say Complex_Main. Then in theory B, \<and> will be ambiguous. To prevent this, make sure to put all your external theory imports in the one theory file where you change the syntax; then have all of your other theories import this one.
I'm a vim fan, but only emacs has this Isabelle/HOL environment. jEdit is great, but I cannot use
using [[simp_trace=true]]
like in emacs.
How to enable "Tracing" in jEdit?
You can indeed use simp_trace in the middle of a proof in Isabelle/jEdit, like so:
lemma "(2 :: nat) + 2 = 4"
using [[simp_trace]]
apply simp
done
Alternatively, you can declare it globally, like so:
declare [[simp_trace]]
lemma "(2 :: nat) + 2 = 4"
apply simp
done
Both give you the simplifier's trace in the "Output" window when your cursor is just after the apply simp statement in jEdit.
If you need a trace depth deeper than 1 (default), you fine-tune it by
declare [[simp_trace_depth_limit=4]]
This example then gives a trace depth of 4.
As others have pointed out, you can use simp_trace. However, you can also use simp_trace_new combined with the "Simplifier Trace" window. This provides improved output over simp_trace:
lemma "rev (rev xs) = xs"
using [[simp_trace_new]]
apply(induction xs)
apply(auto)
done
To view the trace, position the cursor over "apply(auto)" then click on "See simplifier trace". The "Simplifier Trace" window(tab) should open. Click on "Show Trace" and a new window should appear showing a trace for each subgoal.
The Isabelle/Isar reference provides more details:
simp_trace_new controls Simplifier tracing within Isabelle/PIDE applications, notably Isabelle/jEdit.
This provides a hierarchical representation of the rewriting steps performed by the Simplifier.
Users can configure the behaviour by specifying breakpoints, verbosity
and enabling or disabling the interactive mode.
In normal verbosity (the default), only rule applications matching a breakpoint will be
shown to the user. In full verbosity, all rule applications will be logged.
Interactive mode interrupts the normal flow of the Simplifier and defers
the decision how to continue to the user via some GUI dialog.
Alternatively you can specify "using [[simp_trace_new mode=full]]" link here
To see all steps taken by the simplifier.
NOTE: in the previous example, showing the trace of "apply(induction xs)" yields no output.