I'm trying the list example from the official Isabelle tutorial. I replaced the # with : and the # with ++ to have the same syntax as Haskell. Now I get warnings about ambiguities in the AST. I know that I can hide functions with hide_const but this doesn't work for operators in infix notation. How can I hide operators in Isabelle?
The exact warning message is:
Ambiguous input⌂ produces 2 parse trees:
("\<^const>HOL.Trueprop"
("\<^const>HOL.eq" ("\<^const>Map.map_add" ("/<^const>toylist.list.Nil") ("_position" ys))
("_position" ys)))
("\<^const>HOL.Trueprop"
("\<^const>HOL.eq" ("\<^fixed>app" ("\<^const>toylist.list.Nil") ("_position" ys)) ("_position" ys)))
Fortunately, only one parse tree is well-formed and type-correct,
but you may still want to disambiguate your grammar or your input.
Hiding an operator does not delete its notation. There is a separate command no_notation to delete existing notations. In Isabelle/HOL, ++ is bound to map_add as can be seen from the ambiguity warning. You can delete it as follows.
no_notation map_add (infixl "++" 100)
Note that you must repeat the exact precedence parameters with which the notation to be deleted has been declared. There is no easy way to find the notation declaration for a constant, but it is good style to declare notation close to the declaration of the constant; Ctrl-clicking on a constant takes you to its declaration.
Regarding :, this is by default bound to Set.member. You can delete it with no_notation Set.member ("(_/ : _)" [51, 51] 50).
Unless for demonstatory or exploratory purposes, I recommend not to change the default syntax of Isabelle too much. Otherwise, other Isabelle users will find it hard to read your code and your theories will not be compatible with others'. The reason is that when importing different theories, notations are merged additively. Thus, if you delete the notation ++ for map_add in theory A and theory B imports the theories A and some other theory derived from Main but not A, then the ambiguity for ++ is back in theory B.
You can use the command no_notation which takes the same arguments that were used during the notation declaration with the command notation (or within the constant definition).
Both symbols : and ++ are already used by Set.member and map_add respectively. So you have to find these notation declarations and use them in no_notation:
no_notation Set.member ("(_/ : _)" [51, 51] 50)
no_notation map_add (infixl "++" 100)
Then you can proceed in the same way you certainly already have, and by removing the now obsolete syntax for list:
no_notation Cons (infixr "#" 65)
notation Cons (infixr ":" 65)
no_notation List.append (infixr "#" 65)
notation List.append (infixr "++" 65)
term "x : (xs ++ ys)"
The notation for Set.member : would not really miss as there already is the xsymbol/utf-8 notation ∈. I think map_add is not that used, but you could then use the free notation # for it.
Related
I tried to define a definition like this:
theory intext
imports ZF.Int
begin
definition zmod :: "[i,i] ⇒ i" (infixl "$//" 69)
where
"a $// b == 0"
However, it shows error in "$//" the "a $// b == 0":
Inner syntax error⌂
Failed to parse prop
I tried to see if there is infix definition in ZF.Int, and I do find it, but the Isabelle shows error in the theory at the beginning:
Cannot update finished theory "ZF.Int"
May I know does anyone has experience in defining definition with infix operator in Isabelle/ZF could give me some advice?
The character / is a special character in mixfix annotations, therefore you need to escape it using ' as follows:
definition zmod :: "[i,i] ⇒ i" (infixl "$'/'/" 69)
where
"a $// b == 0"
For more information regarding mixfix annotations please refer to The Isabelle/Isar Reference Manual, section 8.2.
Regarding the error message Cannot update finished theory "ZF.Int", this means that Int is part of ZF and cannot be edited.
This is a derivative question of Existing constants (e.g. constructors) in type class instantiations.
The short question is this: How can I prevent the error that occurs due to free_constructors, so that I can combine the two theories that I include below.
I've been sitting on this for months. The other question helped me move forward (it appears). Thanks to the person who deserves thanks.
The real issue here is about overloading notation, though it looks like I now just have a namespace problem.
At this point, it's not a necessity, just an inconvenience that two theories have to be used. If the system allows, all this will disappear, but I ask anyway to make it possible to get a little extra information.
The big explanation here comes in explaining the motivation, which may lead to getting some extra information. I explain some, then include S1.thy, make a few comments, and then include S2.thy.
Motivation: using syntactic type classes for overloading notation of multiple binary datatypes
The basic idea is that I might have 5 different forms of binary words that have been defined with datatype, and I want to define some binary and hexadecimal notation that's overloaded for all 5 types.
I don't know what all is possible, but the past tells me (by others telling me things) that if I want code generation, then I should use type classes, to get the magic that comes with type classes.
The first theory, S1
Next is the theory S1.thy. What I do is instantiate bool for the type classes zero and one, and then use free_constructors to set up the notation 0 and 1 for use as the bool constructors True and False. It seems to work. This in itself is something I specifically wanted, but didn't know how to do.
I then try to do the same thing with an example datatype, BitA. It doesn't work because constant case_BitA is created when BitA is defined with datatype. It causes a conflict.
Further comments of mine are in the THY.
theory S1
imports Complex_Main
begin
declare[[show_sorts]]
(*---EXAMPLE, NAT 0: IT CAN BE USED AS A CONSTRUCTOR.--------------------*)
fun foo_nat :: "nat => nat" where
"foo_nat 0 = 0"
(*---SETTING UP BOOL TRUE & FALSE AS 0 AND 1.----------------------------*)
(*
I guess it works, because 'free_constructors' was used for 'bool' in
Product_Type.thy, instead of in this theory, like I try to do with 'BitA'.
*)
instantiation bool :: "{zero,one}"
begin
definition "zero_bool = False"
definition "one_bool = True"
instance ..
end
(*Non-constructor pattern error at this point.*)
fun foo1_bool :: "bool => bool" where
"foo1_bool 0 = False"
find_consts name: "case_bool"
free_constructors case_bool for "0::bool" | "1::bool"
by(auto simp add: zero_bool_def one_bool_def)
find_consts name: "case_bool"
(*found 2 constant(s):
Product_Type.bool.case_bool :: "'a∷type => 'a∷type => bool => 'a∷type"
S1.bool.case_bool :: "'a∷type => 'a∷type => bool => 'a∷type" *)
fun foo2_bool :: "bool => bool" where
"foo2_bool 0 = False"
|"foo2_bool 1 = True"
thm foo2_bool.simps
(*---TRYING TO WORK A DATATYPE LIKE I DID WITH BOOL.---------------------*)
(*
There will be 'S1.BitA.case_BitA', so I can't do it here.
*)
datatype BitA = A0 | A1
instantiation BitA :: "{zero,one}"
begin
definition "0 = A0"
definition "1 = A1"
instance ..
end
find_consts name: "case_BitA"
(*---ERROR NEXT: because there's already S1.BitA.case_BitA.---*)
free_constructors case_BitA for "0::BitA" | "1::BitA"
(*ERROR: Duplicate constant declaration "S1.BitA.case_BitA" vs.
"S1.BitA.case_BitA" *)
end
The second theory, S2
It seems that case_BitA is necessary for free_constructors to set things up, and it occurred to me that maybe I could get it to work by using datatype in one theory, and use free_constructors in another theory.
It seems to work. Is there a way I can combine these two theories?
theory S2
imports S1
begin
(*---HERE'S THE WORKAROUND. IT WORKS BECAUSE BitA IS IN S1.THY.----------*)
(*
I end up with 'S1.BitA.case_BitA' and 'S2.BitA.case_BitA'.
*)
declare[[show_sorts]]
find_consts name: "BitA"
free_constructors case_BitA for "0::BitA" | "1::BitA"
unfolding zero_BitA_def one_BitA_def
using BitA.exhaust
by(auto)
find_consts name: "BitA"
fun foo_BitA :: "BitA => BitA" where
"foo_BitA 0 = A0"
|"foo_BitA 1 = A1"
thm foo_BitA.simps
end
The command free_constructors always creates a new constant of the given name for the case expression and names the generated theorems in the same way as datatype does, because datatype internaly calls free_constructors.
Thus, you have to issue the command free_constructors in a context that changes the name space. For example, use a locale:
locale BitA_locale begin
free_constructors case_BitA for "0::BitA" | "1::BitA" ...
end
interpretation BitA!: BitA_locale .
After that, you can use both A0 and A1 as constructors in pattern matching equations and 0 and 1, but you should not mix them in a single equation. Yet, A0 and 0 are still different constants to Isabelle. This means that you may have to manually convert the one into the other during proofs and code generation works only for one of them. You would have to set up the code generator to replace A0 with 0 and A1 with 1 (or vice versa) in the code equations. To that end, you want to declare the equations A0 = 0 and A1 = 1 as [code_unfold], but you also probably want to write your own preprocessor function in ML that replaces A0 and A1 in left-hand sides of code equations, see the code generator tutorial for details.
Note that if BitA was a polymorphic datatype, packages such as BNF and lifting would continue to use the old set of constructors.
Given these problems, I would really go for the manual definition of the type as described in my answer to another question. This saves you a lot of potential issues later on. Also, if you are really only interested in notation, you might want to consider adhoc_overloading. It works perfectly well with code generation and is more flexible than type classes. However, you cannot talk about the overloaded notation abstractly, i.e., every occurrence of the overloaded constant must be disambiguated to a single use case. In terms of proving, this should not be a restriction, as you assume nothing about the overloaded constant. In terms of definitions over the abstract notation, you would have to repeat the overloading there as well (or abstract over the overloaded definitions in a locale and interpret the locale several times).
(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 came to this question, when I wanted to check something about the syntax of functor declarations. I came to two contradictory syntax definitions, while the syntax of Standard ML '97, as its name suggest, is supposed to be part of a standard, defined in “The definition of Standard ML — Revised”.
From the book
“The definition of Standard ML — Revised”, by R. Milner, page 14, on Google Books says:
fundec ::= functor funbinf
funbind ::= funid (strid : sigexp) = strexp <and funbind>
I read it as “A functor gets exactly one argument and cannot be said to match a signature”.
From another reliable source
“Standard ML syntax summary”, by L. Paulson, page 2, on PDF says (schema approximately re‑expressed using the same notation as in the definition of SML '97):
FunctorDeclaration ::= functor FunctorBinding <and FunctorBinding>
FunctorBinding ::= Ident ( FunctorArguments ) : Signature = Structure
FunctorArguments ::= Ident : Signature | Specification
I read it as “A functor may get multiple arguments and may be said to match a signature”.
Question
The two documents says different things, so I'm confused. What is the real definition of Standard ML '97? Or am I just miss‑reading the standard definition?
Chapters 2 and 3 of the Definition only give the bare syntax of the language. That's extended by the "derived forms" (i.e., syntactic sugar) defined in Appendix A, which include the funid (spec) form (which is short for funid (X : sig spec end) with X being opened on the RHS).
See here for a complete SML grammar including all derived forms.
As a learning exercise I am trying to implment a parser for the graphviz dot language (The DOT language) using the functional parser library fparsec (FParsec). The language describes graphs.
Looking at the language definition I was compelled to write down the following definition:
let rec pstmt_list = opt(pstmt .>> opt(pchar ';') >>. opt pstmt_list)
Where pstmt and pchar ';' are parsers, .>> and >>. combine an occurence of the left parser with an occurence of the right parser, and opt parsers an optional occurrence of its argument parser as an option value. However this definition does not work complaining "... the resulting type would be infinite ...".
This example is probably most easily understood by taking a look at the DOT language linked above.
I am aware of the following seemingly linked questions:
Are Infinite Types (aka Recursive Types) not possible in F#?
Haskell to F# - declare a recursive types in f#
But my F# knowledge may not be sufficient to translate them yet, if they apply here at all.
FParsec provides special combinators for parsing sequences. Normally you should prefer these combinators to reimplementing them with a recursive function. You can find an overview of the available combinators for parsing sequences here: http://www.quanttec.com/fparsec/reference/parser-overview.html#parsing-sequences
In this example pstmt_list is a sequence of statements separated and optionally ended by semicolons, so you could easily define the parser as
let pstmt_list = sepEndBy pstmt (pstring ";")
The problem is that your pstmt_list parser produces some values of some type, but when you use it in the definition, you wrap the values of this type with additional option type (using the opt combinator).
The F# compiler thinks that the type of the values returned by the parser e.g. 'a should be the same as the wrapped type option 'a (which is, of course, not possible).
Anyway, I don't think that this is quite what you need to do - the .>> combinator creates a parser that returns the result of the second argument, which means that you'll be ignoring all the results of pstmt parsed so far.
I think you probably need something like this:
let rec pstmt_list : Parser<int list, unit> =
parse.Delay(fun () ->
opt(pstmt .>> pchar ';') .>>. opt pstmt_list
|>> (function Some(prev), Some(rest) -> prev::rest
| Some(prev), _ -> [prev]
| _, Some(rest) -> rest
| _ -> [] ))
The additional use of Delay is to avoid declaring a value that refers directly to itself.