Im really new to isabelle, this is my problem
theory MyTheory3
imports Main
begin
(* 3.1) a) define a type natpair, whose elements are pairs of natural numbers.*)
datatype natpair = Natpair "nat × nat"
(*3.1 b)define a function of type natpair ⇒ nat that returns the sum of the elements of a pair of natural
numbers.*)
definition natpair_sum :: "natpair ⇒ nat" where
"Natpair((a::nat) × (b::nat)) = a + b"
end
i get the error
Type unification failed: Clash of types "nat" and "_ set"
Type error in application: incompatible operand type
Operator: (×) :: ??'a set ⇒ ??'b set ⇒ (??'a × ??'b) set Operand: a
:: nat
in addition, can someone show me an example of natpair with a parameterized
constructor
Thanks in advance
youre nuric
Your code has several issues:
Operator (×) is not a constructor for pairs but the Cartesian product of sets; pairs are constructed using the syntax (a, b) or Pair a b.
The definition natpair_sum does not use its name in the equation, that is, the correct syntax is definition natpair_sum :: "natpair ⇒ nat" where "natpair_sum ... = ...".
Pattern matching is not allowed in the left-hand side of a definition; you can use the case construct in the right-hand side of the definition or you can use functions instead.
There is no need to add type annotations for the components of the pair.
As examples, here are two possible definitions for natpair_sum:
definition natpair_sum :: "natpair ⇒ nat" where
"natpair_sum np = (case np of Natpair (a, b) ⇒ a + b)"
fun natpair_sum :: "natpair ⇒ nat" where
"natpair_sum (Natpair (a, b)) = a + b"
As for your last question, I'm not quite sure what you mean by "an example of natpair with a parameterized constructor". Natpair is already a data constructor which takes a pair of nat's as the only parameter.
Related
theory Scratch
imports
"HOL.Fields"
"HOL.Groups"
begin
locale Field_is_group=
fixes F :: "'a :: field"
begin
typedef 'a mul_group = "{x :: 'a set. x ≠ 0}"
end
end
I'm new to Isabelle, and I have learned something about proving in first-order logic but not about data structures. I tried to formalize the proof of the fact that a field has a multiplicative group, but I don't know how to define the multiplicative group. It is the set of the whole field except zero, and a field in Isabelle is defined as a type. By looking about the references, I know I need use typedef, but it fails:
Type unification failed: No type arity set :: zero
Failed to meet type constraint:
Term: λx. x ≠ 0 :: ??'b ⇒ bool
Type: 'a set ⇒ ??'a
The error(s) above occurred in typedef "mul_group"
I started using Isabelle/Simpl and write the following theory according to the user guide:
theory Scratch
imports Simpl.Simpl
begin
hoarestate newvars =
N :: nat
lemma (in newvars) "Γ ⊢ {} ´N :== ´N + 1 {}"
sorry
end
But Isabelle complains that type unification fails:
Type unification failed
Type error in application: operator not of function type
Operator: N_' :: 'a
Operand: s :: ??'a
Simpl itself (including its user guide) successfully compiles.
How can I make it pass?
As Javier Díaz pointed out, importing only Simpl.Vcg instead of Simpl.Simpl does the trick.
The cause of the error seems a name collision against a record defined in Simpl.SyntaxTest. It contains the following record definition:
record 'g vars = "'g state" +
A_' :: "nat list"
AA_' :: "nat list list"
I_' :: nat
M_' :: nat
N_' :: nat
R_' :: int
S_' :: int
B_' :: bool
Abr_':: string
p_' :: ref
q_' :: ref
Isabelle seems to prefer N_' in the record to N in the hoarestate, although the hoarestate is defined later😥. I don't know why this is the case.
I am trying to use the export_code tool for the following definition:
definition set_to_list :: "('a×'a) set ⇒ ('a×'a) list"
where "set_to_list A = (SOME L. set L = A)"
This is not working due to missing code equations for Eps. Now I discovered that there is also a definition:
definition sorted_list_of_set :: "'a set ⇒ 'a list" where
"sorted_list_of_set = folding.F insort []"
However, I am not capable of asserting that ('a ×'a) is a linear order (which would be fine for me, e.g. first comparing the first element and then the second). Can someone help me to either fix my own definition or using the existing one?
To use sorted_list_of_set you can implement the type class linorder for product types:
instantiation prod :: (linorder,linorder) linorder begin
definition "less_eq_prod ≡ λ(x1,x2) (y1,y2). x1<y1 ∨ x1=y1 ∧ x2≤y2"
definition "less_prod ≡ λ(x1,x2) (y1,y2). x1<y1 ∨ x1=y1 ∧ x2<y2"
instance by standard (auto simp add: less_eq_prod_def less_prod_def)
end
You can also import "HOL-Library.Product_Lexorder" from the standard library, which includes a similar definition.
Then you can define set_to_list if you restrict the type parameter to implement linorder:
definition set_to_list :: "('a::linorder×'a) set ⇒ ('a×'a) list"
where "set_to_list A = sorted_list_of_set A"
I can merge two finite maps as follows:
value "fmadd
(fmap_of_list [(1::nat,2::nat)])
(fmap_of_list [(2::nat,3::nat)])"
But when I try to merge a set of maps:
value "ffold fmadd fmempty {|
fmap_of_list [(1::nat,2::nat)],
fmap_of_list [(2::nat,3::nat)]|}"
I get the following error:
Wellsortedness error:
Type nat ⇀⇩f nat not of sort finite
No type arity fmap :: finite
According to definition of fmap, it's domain is finite:
typedef ('a, 'b) fmap = "{m. finite (dom m)} :: ('a ⇀ 'b) set"
morphisms fmlookup Abs_fmap
proof
show "Map.empty ∈ {m. finite (dom m)}"
by auto
qed
But why fmap is not finite?
To answer your immediate question:
But why fmap is not finite?
Every fmap has a finite domain, but it is not necessarily the case that there are only finitely many values of type ('a, 'b) fmap. For example, there are infinitely many finitely-sized mappings from nat to nat.
The problem you're observing is deeper than that: I believe there is no proper code setup for ffold. If I try to compute
ffold funion fempty {|
fset_of_list [(1::nat,2::nat)],
fset_of_list [(2::nat,3::nat)]|}
... the error message is similar. For now, I would recommend rewriting it as fold on lists:
fold fmadd [
fmap_of_list [(1::nat,2::nat)],
fmap_of_list [(2::nat,3::nat)]] fmempty
It's not the same but it might be useful for your application.
I’m doing my first experiments with codatatype, but I’m stuck rather early. I started with this definition of a branching, possibly infinite tree:
codatatype (lset: 'a) ltree = Node (lnext : "'a ⇒ 'a ltree option")
and some definitions work fine:
primcorec lempty :: "'a ltree"
where "lnext lempty = (λ _ . None)"
primcorec single :: "'a ⇒ 'a ltree"
where "lnext (single x) = (λ _ . None)(x := Some lempty)"
but this does not work:
primcorec many :: "'a ⇒ 'a ltree"
where "lnext (many x) = (λ _ . None)(x := Some (many x))"
as I get the error message
primcorec error:
Invalid map function in "[x ↦ many x]"
I could work around it by writing
primcorec many :: "'a ⇒ 'a ltree"
where "lnext (many x) = (λ x'. if x' = x then Some (many x) else None)"
which makes be believe that primcorec needs to “know something about” the function update operator, similar to how fun needs fundef_cong lemmas and inductive needs mono lemmas. But what exactly?
If the codatatype recurses through other type constructors, then primcorec expects that the recursive calls are properly nested in the map functions of these type constructors. In the example, the recursion goes through the function type and the option type, whose map functions are op o and map_option. Consequently, the recursive call to many should have the form op o (map_option many). Hence, the following definition works:
primcorec many :: "'a ⇒ 'a ltree"
where "lnext (many x) = map_option many ∘ [x ↦ x]"
For convenience, primcorec supports a few more syntactic input formats. In particular, the map function for the function type can be also written using lambda abstractions. Additionally, it supports case distinctions and ifs. This is why your second version is accepted. However, when you look at the generated definition many_def, you will see that it is more complicated than with the explicit map functions.
primcorec does not suport registration of arbitrary functions, so you cannot use fun_upd in the original form. Primitive corecursion is syntactical. Maybe in the future there will be a corecursive counterpart to function.
The map functions are explained in the tutorial on datatypes and in this paper.