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).
Related
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.
It seems I can't get the Coq Import system right.
I found pow_succ_r in Coq.Arith.PeanoNat.
So I imported it and hoped it is usable
Require Import Coq.Arith.PeanoNat.
Print pow_succ_r.
I get the following error:
pow_succ_r not a defined object.
Notice the line Module Nat near the top of the documentation. It means that the subsequent declarations are inside the Nat module. So, you can access the symbol as Nat.pow_succ_r.
In general, if you are looking for a symbol, use the Locate command:
Locate pow_succ_r.
(*
Constant
Coq.Arith.PeanoNat.Nat.pow_succ_r
(shorter name to refer to it in current context is Nat.pow_succ_r)
*)
I'm trying to build a CLI. I choose to use 'yang' to do so. I'm new to it and can't find out how to import existing moduls. As exemple I found a module for ospf on github (https://github.com/YangModels/yang/blob/master/vendor/cisco/xe/1631/ietf-ospf.yang) and I would like to import it in my own moduls. Can this be done? how?
EDIT1:
module mininet {
/* name space */
namespace "http://tail-f.com/ns/example/mininet";
prefix mininet;
import ietf-ospf {
prefix ospf;
revision-date 2015-03-09
}
leaf area-id-type {
type yang:area-id-type;
}
}
So I tried to do it this way using Piotr Babij help. Unfortunately this isn't working. What do I need to change?
area-id-type is a typedef of ietf-ospf. The error I have is te following one:
mininet.yang:12:3: error: trailing garbage after module
mininet.yang:12:3: error: unterminated statement
You may import other modules in your own modules by using the import statement. It is described in both RFC 7950 for YANG 1.1 and in RFC 6020 for YANG 1.0. In YANG 1.1 you may import two different revisions of the same module. Other that that, the import statement works the same in both versions.
In practice the basic import looks like this:
module acme-system {
namespace "http://acme.example.com/system";
prefix "acme";
import ietf-yang-types {
prefix "yang";
revision-date 2013-07-15;
}
leaf acme-ip-address {
type yang:dotted-quad;
}
}
If you omit the optional revision-date statement then an undefined module revision is imported. So, in general, it is a good practive to use it.
The mandatory prefix statement lets you to refer to the things in the imported module. In the example the prefix of the imported ietf-yang-types module is yang and, thanks to that, it is clear that yang:dotted-quad refers to a type from that module. In your case you have set the prefix to ospf, so you should have ospf:area-id-type to refer to a type definition from that module. If you import multiple modules you need to ensure their prefixes are unique.
Additionally, you are importing the oldest available revision of the ietf-ospf module. I just hope that this is what you really want to do.
Anyway, once you import a module you are allowed to:
use any grouping and typedef defined at the top level in the imported module or its submodules.
use any extension, feature, and identity defined in the imported module or its submodules.
use any node in the imported module's schema tree in must, path, and when statements, or as the target node in augment and deviation statements.
In the above example the typedef dotted-quad from the ietf-yang-types is used in the acme-system module.
Can someone please tell me the differences between
Require Name.
Require Import Name.
Import Name
?
Require: load an external library (typically from the standard library or the user-contribs/ folder);
Import: imports the names in a module. For example, if you have a function f in a module M, by doing Import M., you will only need to type f instead of M.f;
Require Import: does both Require and Import.
About import statement, google says that https://developers.google.com/protocol-buffers/docs/proto#services :
You can use definitions from other .proto files by importing them. To import another .proto's definitions, you add an import statement to the top of your file.
By default you can only use definitions from directly imported .proto files.
...Sounds great, but what about that :
1.proto :
message M1{
required string foo = 1;
}
2.proto :
import "1.proto";
message M2{
required M1 m_1 = 1;
}
3.proto :
import "2.proto";
message M3{
required M2 m_2 = 1;
}
So, When parsing 3.proto, M1 shouldn't be accessible because 1.proto is not imported publicly from 2.proto.
However, M2 should be, because it is directely imported from 3.proto...
Thus what about M2.m_1 ? how a compiler should generate classes ?
What the documentation means is that if you want to refer to M1 in a file, you must import 1.proto, and if you want to refer to M2 in a file, you must import 2.proto. You do not need to explicitly import implicit/transitive dependencies. It's perfectly fine to use M2 without importing 1.proto.
The compiler actually follows the transitive imports and reads all three files in order to generate code for 3.proto. Moreover, in C++, 3.pb2.h will #include "2.pb2.h" which will in turn #include "1.pb2.h". The rule is only a syntax rule.
Why have this rule? Well, consider if you could directly use M1 in 3.proto without explicitly importing 1.proto, just because you imported 2.proto which itself imports 1.proto. Now consider if, later on, the maintainer of 2.proto decided to remove the field m_1. Now 2.proto doesn't use M1, so the maintainer decides to remove the import of 1.proto. But now 3.proto is broken, because it was relying on the fact that 2.proto imported 1.proto!
This is a common problem with C++ includes. I didn't want to have the same problem in Protobufs, so I made the rule that you must explicitly import all of the files declaring the types that you explicitly use in your own file.