In my project, I am attempting to maintain small hintbases in order to speed up proofs. However, when I am writing Ltac support for such architecture, I couldn't find a way to refer to the various hintbases. Essentially, I want to do the following:
Tactic Notation "myauto" ???(db) := auto with db.
It will be more complicated than that. However, Coq parser seems eagerly parse db to be the concrete name of the hint base, and therefore error message like this will be thrown:
Error: No such Hint database: db.
Any way I can parameterize the hint base option for auto family?
EDIT:
What you are trying to do is currently not working in Ltac.
https://github.com/coq/coq/issues/2417
You can get around your issue by either
rephrasing your issue into a separate question where you give some explanation why you need this kind of automation, where someone might be able to help you solving the initial problem in a different way (not using auto and database parameters)
or
trying out one of the newer Coq tactic libraries, like Ltac2
Old (broken) answer:
In Coq 8.7.2 what you are looking for is the ident argument type.
According to the definition, a Hint database is referenced by an ident:
Create HintDb ident [discriminated]
(see https://coq.inria.fr/distrib/current/refman/tactics.html#Hints-databases for the definition)
Putting
Tactic Notation "test" ident(db) :=
auto with db.
works fine for me.
https://coq.inria.fr/distrib/current/refman/syntax-extensions.html#hevea_command236 contains a list of allowed modifiers.
Related
I'm quite new to coq proof assistant and am still finding my feet.
I've encountered a case which I don't know how to deal with: I tried to use Program Fixpoint tactic to weaken the requirements on my code to later prove the needed properties afterwards as so called Obligations. While most of them were easy, there were two obligations generated goals of which had form [a-quite-simplee-xpr] = [my-function-name]_obligation_3, generally speaking the goals were refering to other obligations which were proved before. I tried unfolding and do substitutions but it didn't really help.
If there's no general solution for such problems I can send the proof script + the screenshot of the obligation to add some context.
Thank you in advance.
One thing that might be happening is that you have types which contain both "data" and "proof" (typically if you're trying to make refinement types with sig, or a custom inductive Type which contains proof terms), and that your functions require proofs of propositional equality, which is generally too strong for such dependent types.
Proof terms should be irrelevant: the simplest way out is to resolve that goal using an axiom from ProofIrrelevance (in the stdlib).
There are axiom-free ways, but I believe they require much more work/expertise.
I have several proofs that follow identical structure. First of them can be finished with trivial, all the other ones with auto with foo_db, where foo_db is a hint database populated with hints after the first proof is complete. I'd like to write an Ltac procedure that uses auto with foo_db to solve all these proofs. However, when running that Ltac to solve the first of my proofs foo_db does not yet exist and so Coq complains: Error: No such Hint database: foo_db.. Is there a way to initialize an empty hint database?
Yes, there's a command Create HintDb that does exactly what you want.
Create HintDb foo_db.
Goal True.
auto with foo_db nocore. (* no hints *)
exact I.
Qed.
For demonstration purposes (to avoid solving the goal), I've also added the pseudo-db nocore to avoid using the standard library's hints. You probably want to just do auto with foo_db, to solve all the goals trivial would have solved.
In my coq development I am learning how to create new tactics tailored to my problem domain, a la Prof. Adam Chlipala.
On that page he describes how to create powerful tactics by wrapping repeat around a match that responds to various interesting conditions. The repeat then iterates, allowing for far-reaching inference.
The use of repeat has a caveat (emphasis mine):
The repeat that we use here is called a tactical, or tactic combinator. The behavior of repeat t is to loop through running t, running t on all generated subgoals, running t on their generated subgoals, and so on. When t fails at any point in this search tree, that particular subgoal is left to be handled by later tactics. Thus, it is important never to use repeat with a tactic that always succeeds.
Now, I already have a powerful tactic in use, auto. It similarly strings together chains of steps, this time found from hint databases. From auto's page:
auto either solves completely the goal or else leaves it intact. auto and trivial never fail.
Boo! I have already invested some effort in curating auto's hint databases, but it seems I am forbidden from employing them in tactics using repeat (that is, interesting tactics.)
Is there some variation of auto that can fail, or otherwise be used correctly in loops?
For example, perhaps this variant fails when it "leaves [the goal] intact".
EDIT: Incorporating auto into loops isn't the "right" way to do it anyway (see this), but the actual question of a failing version of auto is still perhaps interesting.
As mentioned by #AntonTrunov you can always use the progress tactical to make the tactic fail if the goal has not been changed. In the case of auto since it is supposed to solve the goal or leave it unchanged, you can also wrap it in solve [ auto ] which will have the same effect because it will fail if auto does not solve the goal completely (here is the doc for solve).
In my coq development I am learning how to create new tactics tailored to my problem domain, a la Prof. Adam Chlipala. On that page he describes how to create powerful custom tactics by e.g. combining repeat with match.
Now, I already have a powerful one-shot tactic in use, auto. It strings together chains of steps found from hint databases. I have invested some effort in curating those hint databases, so I'd like to continue using it as well.
However this presents a problem. It isn't clear what the "right" way is to incorporate auto's functionality into customized tactics.
For example, since (per its page) auto always either solves the goal or does nothing, putting it inside a loop is no more powerful than calling it once after the loop.
To see why this isn't ideal, consider a hypothetical way to directly call a single "step" of auto, which succeeds if it could make a change (as opposed to only when it solved the goal) and fails otherwise. Such single-steps could be interleaved with custom behavior in a match repeat loop, allowing us to e.g. try contradiction or try congruence at intermediate points within the search tree.
Are there good design patterns for incorporating auto's functionality into custom tactics?
Can auto's behavior be decomposed into "single step" tactics that we can use?
What I would do instead would be to incorporate other tactics within auto.
You can do so by using the Hint Extern num pat => mytactic : mybase command where num is a priority number (0 being the highest priority), pat a pattern to filter when the hint should be used and mytactic and mybase are of course the tactic you want to apply and the base you want to add the hint to (do not use the default core; build up your custom base instead and call it with auto with mybase; if you do not want to include the lemmas from the core base in the search, add the fake base nocore: auto with mybase nocore).
If you start relying on auto very much, I would switch instead to the almost equivalent but better behaved typeclasses eauto with mybase. Contrary to what its name suggests, it is a general purpose tactic that has nothing to do with type classes (as long as you explicitly provide the hint base on which it should be working). One of the main behavior difference to know is that the search depth is unbounded by default. So beware of possible infinite loops or fix a finite limit with the variant typeclasses eauto num with mybase.
I'm looking at writing code in Coq and extracting this code for use in a large Haskell project. I want to build a single module in Coq, prove properties, then use Haskell's module system to prevent violation of these properties (via smart constructors).
I can't find any indication that it's possible to extract Coq code into a Haskell module with an explicit export list. It seems I must hand-modify the extracted Coq code, which isn't a big deal but I want to know if I have this right. Does anyone have an alternate proposal?
I just looked at the latest coq source (r14456). There doesn't seem to be any code to generate an export list.
Seems you'll have to do this yourself.