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).
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.
Let's say I have several proofs based on data structure (or lemma) A. Then, I refactored A to A', is there a general practice / tool facility for Coq to know all proofs are impacted by my refactoring?
Thank you for shedding some light on this matter.
edit1: thank you for all your suggestions, I will give them a try, and get back on this.
Another tool that might be useful is dpdgraph, which makes it possible to display all the usage dependence between various objects.
There is no such tool available, as far as I am aware. What I usually do is to refactor the code and try to repair it. Because of Coq's proofs and typing discipline, once the code compiles again, it is usually the case that it works.
You might want to take a look at PUMPKIN PATCH (GitHub repo). Here's a quote from the project readme file:
This is a prototype plugin for finding patches for broken Coq proofs. To use PUMPKIN, the programmer modifies a single proof script to provide an example adaptation of a proof to a change. PUMPKIN generalizes this example into a reusable patch which can be used to fix other broken proofs.
Not sure if this is exactly what you're looking for but it might be of interest.
I am considering writing tactics which will look at multiple goals and make decision based on that. However, when I use match goal with and stare at a goal, how do I say "please find another goal that looks like this"?
Or rather, a more general question is, how can I switch between goals in Ltac?
As we discussed in the comments, it is the case that achieving this kind of inspection of the current proof goal is currently not possible in Ltac.
However, it may be possible to program such a tactic on the ocaml level or in one of the newer tactic languages like ltac2 or mtac.
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 would like to encode "implies" logic in LogicBlox.
I have a predicate:
Number(n),hasNumberName(n:i)->int(i).
isTrue[n] = i -> Number(n), boolean(i).
And I add some data in that predicate:
+Number(1).
Now, I want to create number 2 and number 3, and the truth value for these two number following this logic rule:
If isTrue[1] is true, then isTrue[2] is true or isTrue[3] is true. (isTrue[1] implies (isTrue[2] or isTrue[3]))
So I create a predicate:
implies[n1,n2,n3] = e -> Number(n1), Number(n2), Number(n3),boolean(e).
Then I try to create a rule like that:
isTrue[n2] = true;isTrue[n3] = true <- isTrue[n1] = true,implies[n1,n2,n3] = true.
But LogicBlox reports:"error: disjunction is not supported in the head of a rule "
So how can I encoding this implies logic in LogicBlox?
From your question it looks like you're asking this question with a Prolog background. If so, then it might be helpful to read a Datalog introduction, for example "What you always wanted to know about Datalog (and never dared to ask)".
The logic you want to express is on purpose not allowed in Datalog, because it requires a solving or search strategy. As opposed to Prolog, Datalog is on purpose restricted in the computational complexity of the programs you can express. As a result of these restrictions it meets important requirement for use in a database management system, most importantly supporting very large data sets. The computational complexity restrictions will be more clear after reading a good introduction to Datalog.
People have studied extensions of Datalog to allow more programs to be expressed (without going to full Prolog, which would result in a more procedural semantics). This particular example is called "Disjunctive Datalog". The hits on Google look good for this if you want to read more. LogicBlox does (at least currently) not implement Disjunctive Datalog because our primary objective is to be a scalable database management system.
LogicBlox does support using a solver for specific programs. A typical example is the knapsack problem. If your problem is expressible as an optimization problem (it almost certainly is, but the formulation usually requires some creativity for things that are not conventional optimization problems), then you could use this feature. The solver functionality is not very well documented in publicly available material yet. Please reach out to us directly if you would like to give this a try.
I assume you are trying to enforce a constraint that 1 -> 2 or 3 ? If so, trying to derive a value using <- is not going to work: if neither 2 nor 3 is present, which one(s) are you telling the system create? Instead, just write the constraint using -> syntax. Constraints are implications, after all (the right arrow syntax is no accident!), and that puts the disjunction on the right hand side where the language allows it. Then, if you ever try to create 1 and neither 2 nor 3 exists, the system will report a constraint failure because the implication was not found to hold.
Also, you don't usually need boolean-valued functions in logic languages; isTrue(x) can just be the set of x which you consider to be "true" (and any not present are "false").