What is the Wellsortedness error in Isabelle.
I encountered a trouble such as:
How can I solve it?
The value command internally uses the code generator for evaluation and the code generator raises the wellsortedness errors. In the above case, Isabelle's type checker infers a type with a type variable for the term mirror Typ, namely 'a tree where the type variable 'a has sort type. Since a 'a tree may contain values of 'a, the code generator also tries to generate code for pretty-printing 'a tree, which is implemented in the type class term_of. This fails however because the inferred type for 'a is type and not term_of, and that is the reason for the well-sortedness error.
The simplest way to avoid the error is to give a monomorphic type explicitly. For example,
value "mirror Tip :: nat tree"
should work.
Related
I was trying to copy a tactic file that might help proving my theorem, however, there seems to be having some problems.
The original tactic is like this:
fun typechk_step_tac tyrls =
FIRSTGOAL (test_assume_tac ORELSE' filt_resolve_tac tyrls 4);
(* Output:
Value or constructor (filt_resolve_tac) has not been declared
*)
I tried to find this tactic in the internet, but there is not much explanation of this. I saw that some theory file in 2009 use this method, and for 2020 one, a theory file use a similar method called filt_resolve_from_net_tac, which I think the types of them are different, so I am not sure about how to use them.
Other than the filt_resolve_tac, the tactic file used a function called ref like this:
val basictypeinfo = ref([]:thm list);
(* Output:
Value or constructor (ref) has not been declared
*)
However, the Isabelle 2020 seems know something about the ref, since when I changed something:
val basictypeinfo = [];
fun addT typelist = (basictypeinfo := (typelist #(!basictypeinfo)));
(* It shows error:
Type error in function application.
Function: ! : 'a ref -> 'a
Argument: basictypeinfo : 'a list
Reason: Can't unify 'a ref (*In Basis*) with 'a list (*In Basis*) (Different type constructors)
*)
It clearly shows that ref is like a type, and it is defined in the Isabelle right?
Therefore the ref in ref([]:the list) should be similar to a casting function, and I found that there is a thing called Unsynchronized.ref which solves the type problem, may I know are they the same thing in this context?
In the later part of the files, there are also some tactic and rule set seems to be not defined, for example:
etac: Value or constructor (etac) has not been declared
(*
I saw Prof. Paulson had shown this tactic in his Isabelle lecture,
but I couldn't find it in the Isabelle manual or the implementation manual,
is the name of it changed?
*)
ZF_typechecks: I couldn't find any rule sets that has this name in the whole ZF directory.
Sorry to have so many questions, it seems that the tactic file is no longer really well-supported by the new Isabelle, are there still people using Isar/ML to define new tactic? Or most people are doing this with the method declaration in the Isabelle? And which part of the Isabelle/Isar reference manual should I read to master this skill? Thank you very much indeed.
When using the quotient_type command I get the following warning: "No map function defined for Example.A. This will cause problems later on".
Here is a minimal example to trigger the warning(tested with Isabelle2017).
theory Example
imports
Main
begin
datatype 'a A = B "'a A" | C
(*for map: map *) (* uncommenting doesn't fix the warning*)
quotient_type 'a Q = "'a A" / "op ="
by (rule identity_equivp)
end
So my questions are:
What is meant by a map function in this context (I only do know the concept of a map function in the context of functors in functional programming)?
What does it have to do with the datatype packages map functions, like one that would be generated by the commented line?
Which problems will one get later on?
The datatype command does not by default register the generated map function with the quotient package because there may be more general mappers (in case there are dead type variables). You therefore must do the functor declaration manually:
functor map_A
by(simp_all add: A.map_id0 A.map_comp o_def)
The mapper and its theorems are needed if you later want to lift definitions through the quotient type. This has been discussed on the Isabelle mailing list.
I am learning Julia and for that purpose I am building a simulation of a scheduler for some non specified task. For this I want to create an abstract type, which represents the idea of state. A task could be in any state Accepted, Unfulfilled, Running, Finished:
abstract RequestState
Then I add some concrete states, which have RequestState as superstate:
immutable StateAccepted <: RequestState
name :: String
end
And because each state is immutable anyway and it doesn't have an interesting structure, all instances are the same, so I instantiate an instance of the above type to use:
const Accepted = StateAccepted("Accepted")
I generate this with a macro, perhaps it is relevant.
Now comes the problem. I want to write a function, which checks valid transitions. I only have a skeleton at this point:
function checkTransition{T <: RequestState, Q <: RequestState}(t :: T, q :: Q) :: Bool
return true
end
I assumed I should read the expression:
T <: RequestState
As something like forall T which is a subtype of RequestState, but I think this is wrong.
I would expect that this code compiles. The problem is that I don't understand the error and also can't find anything in the documentation. Note that this could be, because I am unfamiliar with the language. The relevant error is:
Error During Test
Expression evaluated to non-Boolean
Expression: checkTransition(Accepted,Running)
Value: ResourceScheduler.StateRunning("Running")
ERROR: LoadError: There was an error during testing
in record(::Base.Test.FallbackTestSet, ::Base.Test.Error) at ./test.jl:397
in do_test(::Base.Test.Returned, ::Expr) at ./test.jl:281
in include_from_node1(::String) at ./loading.jl:488
in process_options(::Base.JLOptions) at ./client.jl:262
in _start() at ./client.jl:318
while loading /home/eklerks/.julia/v0.5/ResourceScheduler/test/runtests.jl
How would I make a generic function accepting only arguments of subtypes of RequestState?
EDIT:
As requested the offending test:
#test checkTransition(Accepted, Running)
But this didn't work out, because I forgot to update and install my package after I changed it. Before that change it read:
function checkTransition{T <: RequestState, Q <: RequestState}(t :: T, q :: Q) :: Q
return q
end
Which was the source of the error. Type Q is indeed not a Boolean. I was experimenting with the type system at that moment.
While your code should work, typically one writes
checkTransition(t::RequestState, q::RequestState) = true
instead of using the unnecessary T <: RequestState parameterization. Note that f{T <: X}(::T) should not be read as "for all T subtype of X", but rather "there exists T subtype of X", as this is an existential type and not a universal type.
The error you're getting is due to checkTransition(Accepted,Running) returning a non-boolean, which must be due to a mistake unrelated to the code that you've posted.
I'm a complete beginner to Isabelle, and I must be doing something wrong, as the following seemingly simple test code just doesn't compile for me:
theory testit
imports
"~~/src/HOL/Library/Inner_Product"
begin
thm inner_zero_left
typ "real_inner"
end
In the jedit interface the thm command appears to be working fine (so it's seeing theorems in the Inner_Product import) but the real_inner typ is not. It's complaining
Undefined type name: "real_inner"⌂
Failed to parse type
I get the same error if I try to use real_inner in a theorem.
real_inner is not a type; it's a type class. If you mean ‘a type of the typeclass real_inner’ you need to use a free type variable with the sort annotation real_inner:
typ "'a :: real_inner"
It seems I can't.
I wanna understand why I can't.
It is sure that I can do type 'a entry = Empty | Value of string * 'a * 'a entry;;, so if I want to recursively define a type, I only can go the union route?
Your question is confusing because it only mentions the type you don't want to use! However, I see from your title that you want to use a directly recursive type.
If you want directly recursive types, you need to turn on -rectypes on the command line. This is not something you really want to do most of the time, however. It allows too many types that really aren't what you want.
$ ocaml
OCaml version 4.00.0
# type 'a entry = string * 'a * 'a entry;;
Error: The type abbreviation entry is cyclic
# ^D
$ ocaml -rectypes
OCaml version 4.00.0
# type 'a entry = string * 'a * 'a entry;;
type 'a entry = string * 'a * 'a entry
#
The reason -rectypes isn't enabled by default is that it allows types to be given to many expressions that are actually coding errors. On balance, the extra flexibility isn't worth giving up the extra error detection.
Here's an example I found in an old OCaml mailing list message:
$ ocaml -rectypes
OCaml version 4.00.0
# let f x = x :: x;;
val f : ('a list as 'a) -> 'a list = <fun>
#
With -rectypes turned on, this fairly absurd function is accepted. But really it only works on rather strange list types. Most likely the programmer meant to append the list to itself using # rather than ::. Unfortunately this error won't be detected until much later when -rectypes is on.
As a side comment, and as newacct points out, you would probably soon find that the type in the title isn't so useful. It really can only represent cyclic or infinite structures. This is another reason that working without -rectypes isn't too difficult.
When you do type something = another type, you are doing a type synonym, like a typedef in C. It makes an alias that you can use as a shortcut to refer to another type. It does not define a new type by itself. Hence, it cannot be recursive.
When you do type something = SomeContructor of ..., that defines a new algebraic data type. This can be recursive.
(Haskell and SML are more clear about this; they use type for type synonyms and data (Haskell)/datatype(SML) to define new algebraic data types.)
An algebraic data type does not necessarily need to have more than one alternative. It is syntactically valid to do
type 'a entry = Value of string * 'a * 'a entry
However, in this case, this is probably not useful, because, how could it end?