In Isabelle, one can often hit proof goals where the intermediate type of terms is critical to a proof's correctness. For instance, consider the following lemma converting the nat 42 into an 'a word then back again:
theory Test
imports "~~/src/HOL/Word/Word"
begin
lemma "unat (of_nat 42) = 42"
...
Now the truth of this statement depends on the type of of_nat 42: if it is 32 word, then the statement is true, if it is a 2 word, however, the statement is false.
Unfortunately, I can't seem to get Isabelle to display this intermediate type to me.
I have tried the following:
declare [[show_types]]
declare [[show_sorts]]
local_setup {* Config.put show_all_types true *}
all of which just display:
unat (of_nat (42::nat)) = (42::nat)
In a pinch, one can do:
apply (tactic {* (fn t => (tracing (PolyML.makestring (prems_of t)); all_tac t)) *})
do get a raw dump of the term, but I was hoping there was a better way.
Is there a good way of displaying intermediate term types in a proof goal?
In Isabelle/jEdit you can always "control-hover" (i.e., keep the control-button pressed and hover the mouse) over a constant in order to get additional information. For of_nat in
lemma "unat (of_nat 42) = 42"
This results in
constant "Nat.semiring_1_class.of_nat"
:: nat => 'a word
Now you can recursively do the same on 'a of 'a word and will get
:: len
free type variable
which tells you that 'a is of sort len (by control-clicking len, you could directly jump to the definition of this type class, which is also quite handy).
So the answer to your question is: yes, control-hover in Isabelle/jEdit.
To make Isabelle show you the type of unat in this example, you want to declare the following:
declare [[show_types]]
declare [[show_sorts]]
declare [[show_consts]]
The last line prints the type of each constant used in the goal in the output window. This works both in jEdit and ProofGeneral.
There is a problem with this solution: if unat occurs multiple times with different types, it will print all these instances, but it will not tell you which type instance is which occurrence. Apart from the jEdit hover, I don't know of any solution for that, though.
Running the command:
setup {* Config.put_global show_all_types true *}
seems to do the trick.
The goal unat (of_nat 3) = 3 becomes the hideous (but complete):
goal (1 subgoal):
1. (Trueprop::bool => prop)
((op =::nat => nat => bool)
((unat::'a word => nat)
((of_nat::nat => 'a word)
((numeral::num => nat)
((num.Bit1::num => num) (num.One::num)))))
((numeral::num => nat)
((num.Bit1::num => num) (num.One::num))))
as desired.
It is interesting that a declare [[show_all_types]] does not work; the source looks like it should. Perhaps it is a bug in Isabelle2013?
Related
I am currently attempting to use VST to verify the correctness of a project which involves a global array of doubles. However, when attempting to access the array I have that the head of the array is given as a data_at statement while the rest of the array is given as a sepcon list of mapsto statements and there does not appear to be any way to prove field_compatible for elements beyond the head of the array.
Trying to access elements beyond offset_val 0 seems to inevitably involve proving a size_compatible statement. This is where I run into a problem. Since the alignment of tdouble is set to 4 and the size is set to 8, there seems to be a possibility that the head of the array is at Ptrofs.modulus - 12 making size_compatible false for the next element in the array. Am I going about this the wrong way?
I made a toy example with the same problem that I've mentioned above.
double dbls[] = {0.0, 1.1};
int main() {
double sum;
sum = dbls[0] + dbls[1];
return 0;
}
I will frame my answer in the form of a Coq development:
Require Import VST.floyd.proofauto.
Require Import VST.progs.foo.
#[export] Instance CompSpecs : compspecs. make_compspecs prog. Defined.
Definition Vprog : varspecs. mk_varspecs prog. Defined.
Definition main_spec :=
DECLARE _main
WITH gv : globals
PRE [] main_pre prog tt gv
POST [ tint ] main_post prog gv.
Definition Gprog : funspecs := [ ].
Lemma body_main: semax_body Vprog Gprog f_main main_spec.
Proof.
start_function.
(* Remark 1: it seems to be a bug in VST 2.11.1 (and earlier versions)
that the array is not packaged up into
(data_at Ews (tarray Tdouble 2) ...)
the way it ought to be. This seems to work better for integer
arrays, et cetera.*)
(* Remark 2: you are right to be concerned about alignment, but
VST addresses that issue correctly. Any extern global variable
in a C program, such as your [dbls] array, is aligned at the
biggest possible alignment requirement. VST expresses this
with the "headptr" predicate, and for any identifier id,
(gv id) is a headptr. So therefore, *)
assert_PROP (headptr (gv _dbls)) by entailer!.
(* and you can see above the line, H: headptr (gv _dbls). *)
Print headptr.
(* This shows that (gv _dbls) must be at offset zero within
some block, which guarantees alignment at any type.
One useful consequence is proved by the lemma
headptr_field_compatible: *)
Check headptr_field_compatible.
(* And now, let's apply that lemma: *)
pose proof headptr_field_compatible (tarray tdouble 2) nil _
H (eq_refl _) Logic.I ltac:(simpl; rep_lia).
(* So we see that as long as the pesky 'align_compatible_rec' is proved,
the pointer (gv _dbls) should be 'field_compatible' with the array
type that you want. And it's straightforward though tedious to prove
the 'align_compatible_rec' premise, as follows: *)
spec H0.
apply align_compatible_rec_Tarray; intros.
Search align_compatible_rec.
eapply align_compatible_rec_by_value; [ reflexivity | ].
apply Z.divide_add_r.
apply Z.divide_0_r.
apply Z.divide_mul_l.
apply Z.mod_divide; compute; intros; congruence.
(* Normally, VST users shouldn't have to do this 'by hand'.
We should fix the bug (failure to nicely package the precondition).
But in the interim, perhaps this gives what you need for a workaround.*)
I am trying to understand options in Isabelle (2020), and couldn't understand why some simple expressions of option do not compute or simplify as expected.
For example, I'd expect that
value "some (1::nat)"
should return an "nat option" type, yet, it returns an unspecified type:
"some 1"
:: "'a
More over, from the type signature, I'd expect the the function the return the value "inside" the option, so that "the (some (1::nat))" is just (1::nat).
However,
value "the (some (1::nat))"
returns a seemingly not very useful type:
"the (some 1)"
:: "'a"
, which isn't nat. Then the result isn't very useful, e.g.
value "the (some (1::nat)) + 2"
returns
"the (some 1) + (1 + 1)"
:: "'a"
(I expected the result to be "3::nat")
Is this by design or am I missing something about the, or how options simplify/compute in Isabelle?
( I have no prior knowledge about Isabelle options, and I am just assuming it's similar to Haskell's Maybe. )
A C-click on the shows that the definition is:
datatype 'a option =
None
| Some (the: 'a)
It is Some, not some.
There is a hint to see that some is not defined: the color is not the same as the color from the.
I'm writing a quicksort function for an exercise. I already know of the 5-line functional quicksort; but I wanted to improve the partition by having it scan through the list once and return a pair of lists splitting the original list in half. So I wrote:
fun partition nil = (nil, nil)
| partition (pivot :: rest) =
let
fun part (lst, pivot, (lesseq, greater)) =
case lst of
[] => (lesseq, greater)
| (h::t) =>
if h <= pivot then part (t, pivot, (h :: lesseq, greater))
else part (t, pivot, (lesseq, h :: greater))
in
part (rest, pivot, ([pivot], []))
end;
This partitions well enough. It gives me a signature val partition = fn : int list -> int list * int list. It runs as expected.
It's when I use the quicksort below that things start to break.
fun quicksort_2 nil = nil
| quicksort_2 lst =
let
val (lesseq, greater) = partition lst
in
quicksort_2 lesseq # quicksort_2 greater
end;
I can run the above function if I eliminate the recursive calls to quicksort_2; but if I put them back in (to actually go and sort the thing), it will cease to run. The signature will be incorrect as well, giving me val quicksort_2 = fn : int list -> 'a list. The warning I receive when I call the function on a list is:
Warning: type vars not generalized because of value restriction are instantiated to dummy types (X1,X2,...)
What is the problem here? I'm not using any ref variables; the type annotation I've tried doesn't seem to help...
The main issue is that you're lacking the singleton list base case for your quicksort function. It ought to be
fun quicksort [ ] = [ ]
| quicksort [x] = [x]
| quicksort xs =
let
val (l, r) = partition xs
in
quicksort l # quicksort r
end
which should then have type int list -> int list given the type of your partition. We have to add this case as otherwise you'll never hit a base case and instead recurse indefinitely.
For some more detail on why you saw the issues you were having though:
The signature will be incorrect as well, giving me val quicksort_2 = fn : int list -> 'a list
This is because the codomain of your function was never restricted to be less general than 'a list. Taking a look at the possible branches in your original implementation we can see that in the nil branch you return nil (of most general type 'a list) and in the recursive case you get two 'a lists (per our assumptions thus far) and append them, resulting in an 'a list---this is fine so your type is not further restricted.
[Value Restriction Warning]
What is the problem here? I'm not using any ref variables
The value restriction isn't really related to refs (though can often arise when using them). Instead it is the prohibition that anything polymorphic at the top level must be a value by its syntax (and thus precludes the possibility that a computation is behind a type abstractor at the top level). Here it is because given xs : int list we (ignoring the value restriction) have quicksort_2 xs : 'a list---which would otherwise be polymorphic, but is not a syntactic value. Correspondingly it is value restricted.
I'm trying to do the following simple thing: given a topological space, extract its topology and view it as a poset. For that, I imported Topology.thy and Orders.thy and tried something along these lines
fun undtop :: "'a top ⇒'a partial_order" where
"undtop T = (leq ::"T ⇒ T ⇒ bool" where
"leq x y = (x ⊆ y)")"
where 'a top is the type 'a set set and partial_order is of type 'a=>'a => bool (the theory Orders.thy defines a class class partial_order) . The idea was that some T of type a' top should give the topology and then undtop would pick such a T and associate a partial order leq, viewed as a map T => T => bool. Clearly this is not how it works, so I'd like to ask
1) How would you define a function that picks each T of a certain type and defines a new function with domain T?
2) How to specify that this T of type 'a top is a topology, and not just a random collection of subsets, i.e how do I tell Isabelle that it should obey the axioms of the locale "topology" in Topology.thy?
Thank you for the support, as a beginner I'm still struggling with the syntax and the way Isabelle operates.
Does "Value Restriction" practically mean that there is no higher order functional programming?
I have a problem that each time I try to do a bit of HOP I get caught by a VR error. Example:
let simple (s:string)= fun rq->1
let oops= simple ""
type 'a SimpleType= F of (int ->'a-> 'a)
let get a = F(fun req -> id)
let oops2= get ""
and I would like to know whether it is a problem of a prticular implementation of VR or it is a general problem that has no solution in a mutable type-infered language that doesn't include mutation in the type system.
Does “Value Restriction” mean that there is no higher order functional programming?
Absolutely not! The value restriction barely interferes with higher-order functional programming at all. What it does do is restrict some applications of polymorphic functions—not higher-order functions—at top level.
Let's look at your example.
Your problem is that oops and oops2 are both the identity function and have type forall 'a . 'a -> 'a. In other words each is a polymorphic value. But the right-hand side is not a so-called "syntactic value"; it is a function application. (A function application is not allowed to return a polymorphic value because if it were, you could construct a hacky function using mutable references and lists that would subvert the type system; that is, you could write a terminating function type type forall 'a 'b . 'a -> 'b.
Luckily in almost all practical cases, the polymorphic value in question is a function, and you can define it by eta-expanding:
let oops x = simple "" x
This idiom looks like it has some run-time cost, but depending on the inliner and optimizer, that can be got rid of by the compiler—it's just the poor typechecker that is having trouble.
The oops2 example is more troublesome because you have to pack and unpack the value constructor:
let oops2 = F(fun x -> let F f = get "" in f x)
This is quite a but more tedious, but the anonymous function fun x -> ... is a syntactic value, and F is a datatype constructor, and a constructor applied to a syntactic value is also a syntactic value, and Bob's your uncle. The packing and unpacking of F is all going to be compiled into the identity function, so oops2 is going to compile into exactly the same machine code as oops.
Things are even nastier when you want a run-time computation to return a polymorphic value like None or []. As hinted at by Nathan Sanders, you can run afoul of the value restriction with an expression as simple as rev []:
Standard ML of New Jersey v110.67 [built: Sun Oct 19 17:18:14 2008]
- val l = rev [];
stdIn:1.5-1.15 Warning: type vars not generalized because of
value restriction are instantiated to dummy types (X1,X2,...)
val l = [] : ?.X1 list
-
Nothing higher-order there! And yet the value restriction applies.
In practice the value restriction presents no barrier to the definition and use of higher-order functions; you just eta-expand.
I didn't know the details of the value restriction, so I searched and found this article. Here is the relevant part:
Obviously, we aren't going to write the expression rev [] in a program, so it doesn't particularly matter that it isn't polymorphic. But what if we create a function using a function call? With curried functions, we do this all the time:
- val revlists = map rev;
Here revlists should be polymorphic, but the value restriction messes us up:
- val revlists = map rev;
stdIn:32.1-32.23 Warning: type vars not generalized because of
value restriction are instantiated to dummy types (X1,X2,...)
val revlists = fn : ?.X1 list list -> ?.X1 list list
Fortunately, there is a simple trick that we can use to make revlists polymorphic. We can replace the definition of revlists with
- val revlists = (fn xs => map rev xs);
val revlists = fn : 'a list list -> 'a list list
and now everything works just fine, since (fn xs => map rev xs) is a syntactic value.
(Equivalently, we could have used the more common fun syntax:
- fun revlists xs = map rev xs;
val revlists = fn : 'a list list -> 'a list list
with the same result.) In the literature, the trick of replacing a function-valued expression e with (fn x => e x) is known as eta expansion. It has been found empirically that eta expansion usually suffices for dealing with the value restriction.
To summarise, it doesn't look like higher-order programming is restricted so much as point-free programming. This might explain some of the trouble I have when translating Haskell code to F#.
Edit: Specifically, here's how to fix your first example:
let simple (s:string)= fun rq->1
let oops= (fun x -> simple "" x) (* eta-expand oops *)
type 'a SimpleType= F of (int ->'a-> 'a)
let get a = F(fun req -> id)
let oops2= get ""
I haven't figured out the second one yet because the type constructor is getting in the way.
Here is the answer to this question in the context of F#.
To summarize, in F# passing a type argument to a generic (=polymorphic) function is a run-time operation, so it is actually type-safe to generalize (as in, you will not crash at runtime). The behaviour of thusly generalized value can be surprising though.
For this particular example in F#, one can recover generalization with a type annotation and an explicit type parameter:
type 'a SimpleType= F of (int ->'a-> 'a)
let get a = F(fun req -> id)
let oops2<'T> : 'T SimpleType = get ""