In Proof General (with Coq 8.5), I executed the following:
Require Import Arith.
Eval cbv delta in Nat.add_comm 3 7.
The output is
Nat.add_comm 3 7 : 3 + 7 = 7 + 3
However, Print Nat.add_comm. gives a long and complicated function taking two nats as input. I expected my code to expand the definition of Nat.add_comm, which is what Eval cbv delta in _. does in similar situations. As a beginner, I know there is a naive misconception lurking. What am I missing?
Expanding a bit on Daniel's comment, cbv delta will unfold an identifier if
it has a body (i.e., is not a context variable, axiom, field in a module argument to the current module functor, bound variable, etc.), and
it's body was given transparently, i.e., either the proof script was closed with Defined rather than Qed or the body was given via := or the automatic obligation tactic (for Program Definition) or typeclass resolution (for Instances without a body), and
it has not been marked opaque via Opaque id or Strategy opaque [id], and
it was not created by "module-locking" another constant, i.e., defined within a module (or module functor) with a module-type ascription via : rather than <: (exception: if the module type itself provides the body for the constant)
Note that, at present, vm_compute can get around 3 (and the unification engine can too, but compute, lazy, cbv, hnf, cbn (usually), simpl (usually), and red cannot), but nothing will get around the others.
Related
I'm learning Ltac2 and reading the official documentation of coq 8.13.2.
I do not get what role Control.refine play in the evaluation inside of quotations, as there doesn't seem to be a lot of explanations to this function.
For example, using variables in tactic expressions inside a constr quotation should be done by: constr:(... $x ...), where $x is the syntactic sugar of ltac2:(Control.refine (fun () => x)).
Why does, say simply, ltac2:(x) not work? (and it indeed doesn't, as coq gives an error of Error: Cannot infer an existential variable of type ..., at the position where the constr represented by x should be inserted).
So my questions are:
What does Control.refine do in general?
It seems to be an idiom to sometimes do this: constr:( ... ltac2:(Control.refine (fun () => ...) ...), in what situation where such anti-quotation idiom should (or shouldn't) be used?
Thanks.
The ltac2:(...) in-term quotation expects an Ltac2 term of type unit, not of type constr. Actually, your example should trigger a warning because of this.
Since the content of the quotation has type unit, it means that it can only act through side-effects. The warning tells you that the value returned by the quotation will be discarded. In particular, it cannot be used to fill the hole.
Rather, the semantics of the quotation is to evaluate its content inside a goal Γ ⊢ A where Γ is the current list of hypotheses, and A the inferred type of the hole. It is expected that doing this will solve the goal, and the resulting partial proof will be used as the Coq term filler for that hole. This is precisely the rôle of Control.refine : (unit -> constr) -> unit. It takes a (for technical reasons, thunked) term as an argument and uses it to solve the goal(s) under focus.
What happens in your example is that you provide a term that is just ignored, the goal is left untouched and the quotation rightfully complains that it was not solved.
Regarding your second point, I cannot really tell. It depends on what you want do do. But in general, if you stick to antiquotations $x I would consider this more readable. It is not always possible to do so, though, e.g. if the term being built depends on a context introduced in the constr:(...) quotation.
I'd like to view the definition of a Standard Library theorem which I found through Search. I think seeing the definition will help me complete a similar theorem.
Doing Print Rdiv_lt_0_compat. yields:
Rdiv_lt_0_compat =
fun (a b : R) (H : (0 < a)%R) (H0 : (0 < b)%R) =>
Rmult_lt_0_compat a (/ b) H (Rinv_0_lt_compat b H0)
: forall a b : R, (0 < a)%R -> (0 < b)%R -> (0 < a / b)%R
Argument scopes are [R_scope R_scope _ _]
Setting Set Printing All. doesn't help. There's nothing extra available in the docs page.
The whole Coq system is based on the idea Proofs are programs, logical formulas are types. When you consider a theorem, it is a proof (a program) and its statement is a logical formula (the type of a program). In the very
first years of Coq, there was no tactic language, every proof was defined using the same keywords as when defining a program.
After a few years, it was recognized that writing the programs entirely by hand was long and tiresome, so a tactic language was invented to explain how to construct the proof-programs in a shorter and less difficult way. But what is recorded and eventually checked are still the programs that you see using Print.
When building a proof-program, the tactic intros constructs anonymous function expressions (also known as lambdas, usually written with the keyword fun, and apply constructs an application of a function to a certain number arguments, which apply infers or leaves to the user as goals. The tactics induction and rewrite are similar, but they apply theorems that are not
given by the user. The tactic destruct essentially produces a piece of programs that is a pattern-matching construct.
With Rdiv_lt_0_compat, you are lucky that the proof built by the tactic is quite short. Often, proofs written using tactics produce programs that are much longer.
If instead of the program, you want to see the sequence of tactics that generated it, you need to find it in the sources of the system, because this
is not kept in the memory of the proof assistant. Here are the clues.
Require Import Reals.
Locate Rdiv_lt_0_compat.
the answer is Constant Coq.Reals.RIneq.Rdiv_lt_0_compat
This sequence of names indicates the hierarchy of modules in which the theorem is kept. The first name Coq expresses that this theorem is in the Coq sources, essentially in directory ...theories/, the second name Reals, indicates that you should look in tge sub directory ...theories/Reals.
The fourth name should not be used as a directory name, but as file name. So you should look in the file RIneq.v
So go an look in https://github.com/coq/coq/tree/v8.12/theories/Reals/RIneq.v and you will probably find the script fragment that was used to generate your theorem (for the 8.12 version of Coq). I just checked, the theorem appears at line https://github.com/coq/coq/blob/c95bd4cf015a3084a8bddf6d3640458c9c25b455/theories/Reals/RIneq.v#L2106
The sequence of names provided by Locate is not a sure way to find the file where the script for a theorem is stored. The correspondence between the long name and the file path is broken when the theorem is defined using modules and functor instantiation. In that case, you have to rely on stronger knowledge of how the Coq system works.
In the current version of the Software Foundations, the relevant explanation is formulated with intentional leeway.
First, we've used the keyword Theorem instead of Example.
This difference is mostly a matter of style; the keywords
Example and Theorem (and a few others, including Lemma,
Fact, and Remark) mean pretty much the same thing to Coq.
(I put the wording used to introduce uncertainty in bold.)
In an earlier version of, evidently, the same writing, it was put strongly:
The form of this theorem and proof are almost exactly the same as the examples above: the only differences are that we've added the quantifier ∀ n:nat and that we've used the keyword Theorem instead of Example. Indeed, the latter difference is purely a matter of style; the keywords Example and Theorem (and a few others, including Lemma, Fact, and Remark) mean exactly the same thing to Coq.
(I put words introducing strength in bold.)
Looking at the official documentation, all of these words, and more, belong to the same grammatical category «assertion keyword»:
assertion_keyword ::= Theorem | Lemma
Remark | Fact
Corollary | Property | Proposition
Definition | Example
There are further two sections explaining how these keywords work: «Definitions» and «Assertions and proofs». In short:
Definitions extend the environment with associations of names to terms.
— And:
An assertion states a proposition (or a type) of which the proof (or an inhabitant of the type) is interactively built using tactics.
But, as far as I see, a theorem also extends the environment, and an example can be built with tactics. So, I am not seeing where these things are different. But the Software Foundation is a clever book. If they chose to be uncertain, there must be a reason?
As of today the differences are minimal, and could be summarized as:
Theorem/Example/Definition/... do produce different entries in the documentation; this is the most relevant difference.
Some forms such as Theorem don't support the syntactical form Theorem foo := nat. for non-interactive mode, which is supported by Definition for example.
Another non-trivial difference is whether you use the interactive mode or not. That is to say:
Definition foo : Type := nat.
and
Definition foo : Type. Proof. apply nat. Qed.
will take slightly different code paths due to the second creating an interactive proof; the codepath when the definition gets sent to the kernel is a bit different, but Coq 8.12 should unify them for all practical purposes, just marking the second proof as opaque.
One difference I've seen is that Definitions can give an immediate definition, whereas Lemma and Theorem can't.
Definition one := 1.
Lemma two := 2. (* syntax error *)
Theorem three := 3. (* syntax error *)
Out of the rest, only Example works.
Remark four := 4. (* syntax error *)
Fact five := 5. (* syntax error *)
Corollary six := 6. (* syntax error *)
Property seven := 7. (* syntax error *)
Proposition eight := 8. (* syntax error *)
Example nine := 9. (* works! *)
I'm extending an existing project (Featherweight Java formalization),
and there are a number of constants, such as:
Notation env := (list (var * typ)).
What would change if I used Definition instead:
Definition env := (list (var * typ)).
Why did the author use Notation here?
Whenever you try to apply or rewrite with a lemma, there's a component in Coq called the unifier that tries to find out how to instantiate your lemma so that it can work with the situation at hand (and checking that it indeed applies there). The behavior of this unifier is a bit different depending on whether you use notations or definitions.
Notations are invisible to Coq's theory: they only affect the parsing and printing behavior of the system. In particular, the unifier doesn't need to explicitly unfold a notation when analyzing a term. Definitions, on the other hand, must be explicitly unfolded by the unifier. The problem is that the unifier works heuristically, and cannot tell with 100% certainty when some definition must be unfolded or not. As a consequence, we often find ourselves with a goal that mentions a definition that the unifier doesn't unfold by itself, preventing us from applying a lemma or rewriting, and having to manually add a call to unfold ourselves to get it to work.
Thus, notations can be used as a hack to help the unifier understand what an abbreviation means without manual unfolding steps.
I am trying to understand the exact meaning of the : (colon) in Coq/ssreflect proofs in terms of non-ssreflect Coq.
I read that it has something to do with moving things to the goal (like generalize??) and is the opposite of =>, which move things to the hypotheses. However, I often find it confusing because proofs work either way with or without the :. Below is an example from a tutorial:
Lemma tmirror_leaf2 t : tmirror (tmirror t) = Leaf -> t = Leaf.
Proof.
move=> e.
by apply: (tmirror_leaf (tmirror_leaf e)).
Qed.
where,
tmirror_leaf
: forall t, tmirror t = Leaf -> t = Leaf
is a lemma that says if the mirror of a tree is a leaf, then the tree is a leaf.
I don't understand why we need the : here and not merely do the Coq apply. In fact, if I remove the :, it works just fine. Why does it make a difference?
Indeed, apply: H1 ... Hn is to all effects equivalent to move: H1 .. Hn; apply. A more interesting use of apply is apply/H and its variations, which can interpret views.
I think I found the answer while reading the SSReflect documentation. Essentially, ssr has redefined tactics like apply such that it operates on the first variable of the goal instead of something in the context. That's why the : is used in apply: XX. in the ssr way (which is equivalent to move: XX; apply.), and it also works if : is omitted as that is the traditional Coq way.
Quoting the documentation:
Furthermore, SSReflect redefines the basic Coq tactics case, elim, and
apply so that they can take better advantage of ':' and '=>'. These
Coq tactics require an argument from the context but operate on the
goal. Their SSReflect counterparts use the first variable or constant
of the goal instead, so they are "purely deductive":
they do not use or change the proof context. There is no loss since
`:' can readily be used to supply the required variable.