Comments (14)
Let's see what the Coq devs say in coq/coq#17199. I don't quite understand what the warning is about either...
from pg.
Dear @RalfJung, thanks for your feedback.
I can reproduce this behavior, but I wouldn't call this a "bug", as omit-proofs precisely ignores the whole proof script reflexivity. Qed.
proof and replaces it with Admitted.
, we get:
Section test.
Let Fact: 0 = 0.
Proof. Admitted.
(* Warning: Let definition Fact declared as an axiom. [let-as-axiom,vernacular]
Fact is declared *)
so I guess we can just mark this issue as wontfix / upstream.
from pg.
I think it is a bug to get a warning here. Enabling the "omit proofs" feature should just make things go faster, it shouldn't cause any other side-effects like this.
Though I can imagine that fixing this bug might be hard due to Coq constraints.
from pg.
This is just an upstream warning.
Actually, I can understand this warning that in the presence of an Admitted.
proof and a local definition (Let
),
there is some risk that the generated axioms forgets or doesn't list in good order the section's hypothesis.
from pg.
But precisely, this can be handled by the Proof using …
clause :)
I'll come with an example.
from pg.
Let me just say that the user experience here is quite bad: I have a huge file that used to always work fine, and now suddenly I get this strange warning. I spend a bunch of time to figure out what this is about (there's no line number or anything that would even tell me where in my proof script the issue arises), only to realize that actually my proof script is completely fine and the warning is caused by "omit proofs".
It's an upstream warning about code I didn't write, and a warning that doesn't indicate anything wrong with my code. If that's not a bug I don't know what is.^^
from pg.
Hi! Yes I understand your point.
Actually I'm not really sure of the "usefulness" caused by this upstream warning.
In my second comment, I had guessed it could be related to the risk that Coq generalizes section hypothesese too eagerly.
I'm not sure of the intent, but that looks plausible.
But in this case, lemmas fact2 and fact3 below involving Proof using …
shouldn't raise this warning as the generalization at section-closing-time is properly handled in this case.
Section test.
Hypothesis hyp : True.
Hypothesis hyp2 : True /\ True.
Let fact1: 0 = 0.
Proof. Admitted.
(* > Proof. Admitted.
> ^^^^^^^^^
Warning: Let definition fact1 declared as an axiom. [let-as-axiom,vernacular]
fact1 is declared
*)
Let fact2: 0 = 0.
Proof using hyp2. Admitted. (* only use hyp2 *)
(* > Proof using hyp2. Admitted.
> ^^^^^^^^^
Warning: Let definition fact2 declared as an axiom. [let-as-axiom,vernacular]
fact2 is declared
*)
Let fact3: 0 = 0.
Proof using Type. Admitted. (* placeholder to use no section hyp *)
(* > Proof using Type. Admitted.
> ^^^^^^^^^
Warning: Let definition fact3 declared as an axiom. [let-as-axiom,vernacular]
fact3 is declared
*)
End test.
Check fact1.
(* fact1 *)
(* : True -> True /\ True -> 0 = 0 *)
Check fact2.
(* fact2 *)
(* : True /\ True -> 0 = 0 *)
Check fact3.
(* fact3 *)
(* : 0 = 0 *)
from pg.
To address the usability issue, I think Coq should disable the warning, at least when a Proof using …
clause is included, or ideally always, for simplicity. Feel free to open an issue upstream if you can!
In the meantime, you can just disable this warning in your _CoqProject;
and I'm going to add a comment in the PG documentation…
I'm sorry if the experience is not as smooth as expected currently, but actually doing C-u C-c C-RET
is precisely intended as a syntactic facility for replacing on-the-fly whole proofs with Admitted
, which is not an exotic workflow… (I was doing this everytime before omit-proofs… without a shortcut 😅)
from pg.
In the meantime, you can just disable this warning in your _CoqProject;
for the record, the exact snippet is:
_CoqProject
-arg -w -arg -let-as-axiom
from pg.
from pg.
Disabling omitting proofs for Let
makes sense to me.
from pg.
Disabling omitting proofs for
Let
makes sense to me.
Yes, this seems to be the natural solution after the discussion in coq/coq#17199 (comment)
However, note that as pointed out by the coq devs, your use case of Let…Qed
is somehow deprecated! at the very best, the cooked proof terms are not opaque.
So I see another solution for you, which does not require changing PG:
replace Let…Qed.
with either Lemma…Qed.
or Let…Defined.
And I realize all this discussion took place thanks to this warning… which was useful actually :)
from pg.
Yeah we had no idea this was deprecated, it has worked fine for us.^^
from pg.
See also #689.
from pg.
Related Issues (20)
- Update https://proofgeneral.github.io/ HOT 2
- `coq-accept-proof-using-suggestion 'always` incorrectly believes that `proof` is a proof directive HOT 4
- Hitting 'tab' to indent just throws an error HOT 6
- Broken link in Ch. 11 of User's Manual
- ProofGeneral does not handle "Proof term." directives HOT 11
- Feature request: sparate commands for jumping to current point with/without omitting proofs HOT 7
- *response* buffer only showing last output HOT 3
- Tons of warnings when using certain PG features HOT 11
- "Omit proofs" breaks other proofs because it also skips hints HOT 14
- whitelist for admissible commands inside proofs HOT 17
- PG incorrectly interprets `}.` as a single token, which results in incorrectly accepting files that coqc rejects
- test_wholefile.v incompatible with 8.17 HOT 1
- Scheme ... with is indented improperly HOT 1
- Merging the Abella fork of PG HOT 10
- Automatic indenting for Easycrypt HOT 1
- generic/pg-goals.el shouldn't be executable HOT 1
- confusing error on incorrect _CoqProject file
- Colors don't work in emacs-nox HOT 1
- Compile-before-require setting does not presist HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pg.