I want to use lemma (count_occ_In)related to count_occ function from library.I have Imported library in the Coq Script. But still I am unable to use it. If I copy count_occ & eq_dec from library in the scipt,then it works. My question is why I should redefine function when I have included library module. Please guide me how to write lemma by adding the library module only(Not defining the functions again)?.
With the additional information this should work for you:
Require Import List Arith.
Import ListNotations.
Check count_occ.
Search nat ({?x = ?y} + {?x <> ?y}).
Definition count_occ_nat := count_occ Nat.eq_dec.
Definition count_occ_In_nat := count_occ_In Nat.eq_dec.
Check count_occ_nat.
Check count_occ_In_nat.
See how I used Check to find which arguments count_occ takes and how I used Search to find a suitable instance for the decidability of equality function.
count_occ is written like this because it should work for lists of any type with decidable equality, but then to use it, you need a proof that for your type equality is decidable, and you have to give this explicitly.
In modern definitions one makes such arguments implicit and uses type classes to automatically fill in information like decidable equality, but count_occ has an explicit argument for that, so you have to supply it.
Related
I cannot find a standard library == function which is overloaded and returns a boolean (or a sumbool, or something I can compute with). I would like to be able to do
3==5
and
"hello" == "hello"
without having to specify the type of the arguments. I would be surprised if Coq does not have this feature for equality types; could someone tell me where to find it? I have a feeling it has something to do with ssreflect but I cannot figure it out.
Thanks.
Ssreflect has the eqType class, which has exactly what you need:
From mathcomp Require Import ssreflect ssrfun ssrbool eqtype.
Check (3 == 5).
Most standard types have an equality operator defined in ssreflect. Unfortunately, strings are not one of them, though it is not to hard to roll up your own. (The Deriving library ships with an instance, but it is not marked as stable yet.)
I have a module and I need to specialize one of its argument. I want to use natural numbers instead of arbitrary UsualDecidableTypeFull. How can I obtain such behaviour in Coq?
I defined some module:
Module PRO2PRE_mod
(SetVars FuncSymb PredSymb PropSymb: UsualDecidableTypeFull).
(* ... *)
End PRO2PRE_mod.
Then I specialized the last of the arguments PropSymb.
Require Import Arith.PeanoNat.
Module m2 : UsualDecidableTypeFull.
Definition t:=nat.
Definition eq := #eq nat.
Definition eq_refl:=#eq_refl nat.
Definition eq_sym:=#eq_sym nat.
Definition eq_trans:=#eq_trans nat.
Definition eq_equiv:Equivalence eq := Nat.eq_equiv.
Definition eq_dec := Nat.eq_dec.
Definition eqb:=Nat.eqb.
Definition eqb_eq:=Nat.eqb_eq.
End m2.
This module needs specialization of PropVars:
Module SWAP_mod
(SetVars FuncSymb PredSymb : UsualDecidableTypeFull).
Module PRE := PRO2PRE_mod SetVars FuncSymb PredSymb m2.
Import PRE.
Theorem test : m2.t.
try exact 0. (* ERROR HERE! *)
Abort.
End SWAP_mod.
How to use theorems about natural numbers inside the last module? (I think I don't understand something about using modules... Maybe we need somehow to coerce the type 'm2.t' to the type 'nat'?)
Indeed, the use of : UsualDecidableTypeFull in the definition of m2 hides completely the implementation details of m2. From the outside, m2.t is an unknown type.
Sometimes, this is exactly what you want. For example, you may want to abstract away a type defined in a module so that the users cannot manipulate values of this type without using the functions that you gave to them in the module. You can thus ensure that they will not break some invariants.
However, in your case, you need to remember that m2.t is actually nat, you have at least these two options:
Make the interface transparent with Module m2 <: UsualDecidableTypeFull. When using this, Coq just verifies that the definition of the module complies with the signature, but does not hide the content of the module.
If you still want to hide part of the module, you can also use
Module m2 : UsualDecidableTypeFull with Definition t := nat.
In this case, from the outside, m2.t is known to be nat, but the other fields of m are masked. For instance, the body of m2.eqb is hidden.
I find that I'm frequently writing code like this:
Fixpoint get_fresh w (Γ : Ctx) : Pat w * Ctx:=
match w with
...
| w1 ⊗ w2 => let (p1, Γ1) := get_fresh w1 Γ in
match Γ ⋓ Γ1 with
| None => (dummy_pat _, dummy_ctx)
| Some Γ' => (p1,Γ')
end.
Where the None branch will never be entered. (Here, it's impossible to enter the branch, sometimes we will never enter the branch on an appropriate input.)
What's the best way to implement the dummy values that should never be returned?
An easy approach is to simply declare
Parameter dummy_pat : forall W, Pat W.
Parameter dummy_ctx : Ctx.
But that sounds seems like bad practice - for all the user knows Ctx and Pat W might have no inhabitants. (This is especially true for dependent types like Pat W.)
I could give simple definitions for dummy_pat and dummy_ctx but I don't want users reasoning about this branch. I could declare dummy_pat and dummy_ctx opaque, but opacity is disturbingly easy to reverse.
Finally, I guess I could declare these as the a projection from a sigma type, but it seems like that would be confusing, and I'm not sure it addresses the problem of reasoning about that case.
(Note that I don't want to intrinsically prove that these branches are inaccessible, using Program or otherwise. I find these functions very difficult to write and to use.)
Any suggestions?
The following way of declaring a module may have better opaqueness guarantees (but if I'm wrong I'd be very interested to know!):
Module Type DummySig.
Parameter dummy_pat : forall W, Pat W.
Parameter dummy_ctx : Ctx.
End DummySig.
Module Import Dummy : DummySig.
Definition dummy_pat := (* some simple definition *)
Definition dummy_ctx := (* some simple definition *)
End Dummy.
Explanation
Module Import Dummy : DummySig. is short for Module Dummy : DummySig followed by Import Dummy. after the closing End Dummy. command.
Module Dummy : DummySig. declares a module with module type (or signature) DummySig, and also seals the module so that only the information declared in DummySig is visible about this Dummy module.
This is a strong abstraction boundary that hides all of the implementation details. In particular, a Parameter in DummySig makes a definition opaque in Dummy, and identifiers defined in Dummy that do not appear in DummySig are not visible at all from outside the module.
As far as I can tell, this opaqueness is irreversible, which is the key point here.
For comparison, the two other ways of declaring modules are:
Module M. exposes everything in the module M, so it is mostly a kind of namespacing.
Module M <: MSig., also exposes everything in M, while checking that it implements the signature MSig (defined via Module Type MSig.), without the "sealing" aspect of Module M : Sig..
Other proposed solutions
You can also turn the dummies into actual parameters, either via a module functor...
Module MyProject (Dummy : DummySig).
Import Dummy.
...
or a section; to avoid having to pass dummies around, a type class may be useful.
Class Dummy (A : Type) := { dummy : A }.
Section Dummies.
Context `{forall W, Dummy (Pat W)}.
Context `{Dummy Ctx}.
...
At the end of the day I wonder whether it is really bad that users can reason about inaccessible branches.
I need to use the part of the standard library called Coq.Arith.PeanoNat (https://coq.inria.fr/library/Coq.Arith.PeanoNat.html).
I've tried either importing the entire Arith library or just this module, but I can't use it either way.
Every other library I've tried works just fine. When I do Require Import Bool. I compile and I can use it correctly. Upon Print Bool. I can take a look at all the functions inside in the next format:
Module
Bool
:= Struct
Definition...
.
.
.
End
When I do either Require Import Arith.PeanoNat. or Require Import Arith. I get this as immediate output:
[Loading ML file z_syntax_plugin.cmxs ... done]
[Loading ML file quote_plugin.cmxs ... done]
[Loading ML file newring_plugin.cmxs ... done]
<W> Grammar extension: in [tactic:simple_tactic], some rule has been masked
<W> Grammar extension: in [tactic:simple_tactic], some rule has been masked
<W> Grammar extension: in [tactic:simple_tactic], some rule has been masked
<W> Grammar extension: in [tactic:simple_tactic], some rule has been masked
<W> Grammar extension: in [tactic:simple_tactic], some rule has been masked
When I ask Coq Print Arith.PeanoNat it outputs: Module Arith := Struct End, it seems to be empty. When I try to use anything from the library, for example le_le under boolean comparisons, I get the standard Error: leb_le not a defined object. I have updated Coq and the libraries, and I have no idea of what might be going on here. I'd appreciate your input in fixing this library problem.
If I am not mistaken, Require is the keyword to load a file. Import has to do with managing name spaces. Often they are used together, as in Require Import PeanoNat., but they are really doing two different things.
When coq files (DirName/FileName.vo) are loaded with Require, it is as if the contents of FileName.vo is wrapped in Module DirName.FileName ... End. Everyting defined in the file is then accessed with DirName.FileName.Name.
The file can itself have modules M inside of it, and to get to M's contents, one has to type DirName.FileName.ModuleName.Name1 etc.
Import is used to get all the definitions up to the top level. By doing Import DirName.FileName.ModuleName the module Name1 is now imported to the top level, and can be referenced without the long path.
In your example above, the file Arith/PeanoNat.vo defines the module Nat. Actually, that is all it defines. So if you do Require Import Arith.PeanoNat you get PeanoNat.Nat at the top level. And then Import PeanoNat.Nat will bring Nat to the top level. Note that you can't do Require Import PeanoNat.Nat because it is no .vo file.
Coq can sometimes find a .vo file without you having to specify the whole path, so you can also do Require Import PeanoNat. and coq will find the file. If you wonder where it found it, do Locate PeanoNat.
Coq < Require Import PeanoNat.
Coq < Locate PeanoNat.
Module Coq.Arith.PeanoNat
Another Nat is also available from another place than PeanoNat.
Coq < Require Import Nat.
Warning: Notation _ + _ was already used in scope nat_scope
Warning: Notation _ * _ was already used in scope nat_scope
Warning: Notation _ - _ was already used in scope nat_scope
Coq < Locate Nat.
Module Coq.Init.Nat
So, you don't Import a library, you Require it. You use Import to not have to use the full path name. I hope this helps you debug what is happening.
When I try Print Arith.PeanoNat, the output is slightly different: I get Module PeanoNat := Struct Module Nat End and then even though leb_le is not in scope, Nat.leb_le is.
(I run 8.5beta2 in case that's relevant).
I'm new to coq and I am trying to use the "int" type from ZArith.Int but coq cannot find it.
Require Export ZArith Int.
Open Scope Int_scope.
when I use "int" in my definitions such as (... -> int -> ...), coq cannot find it. How can I properly load it along with the library's operations?
That library actually formalizes an abstract module of integers, that can be later instantiated with a concrete implementation. In Coq, the implementation of integers from the standard library is called Z. There's an instance of the Int module type in terms of Z defined in that library, called Z_as_Int; to use the definitions available there with Z, you just need to refer to them prefixed by the module name, e.g. Z_as_Int._0. However, given that most theorems are proven directly over Z, without relying on the interface defined in Int, it is probably better to just use Z directly.