coq-club AT inria.fr
Subject: The Coq mailing list
List archive
- From: Francois Pottier <Francois.Pottier AT inria.fr>
- To: coq-club AT inria.fr
- Subject: [Coq-Club] A smarter "induction;econstructor" combo?
- Date: Mon, 21 May 2012 19:02:19 +0200
Dear list members,
When formalizing the meta-theory of a typed programming language, it is often
the case that one needs to transform a type derivation into a new type
derivation that has the same shape. This happens when proving renaming
lemmas, substitution lemmas, weakening lemmas, etc.
Ideally, the proof of such a lemma should be of the following idealized form:
induction 1; (* performs case ananalysis on the original derivation *)
econstructor; (* builds one node of the new derivation *)
eauto (* applies the induction hypotheses, etc. *)
In many simple situations, this works. However, I am facing situations where
this does *not* work because of the following problem: the tactic
"econstructor" is dumb. It applies the first constructor that seems to be
applicable. If there is just one, fine. Sometimes, however, several
constructors are applicable, so in some cases, "econstructor" will pick the
wrong one, and the above idealized proof will not work.
This is a shame, because I *know* which constructor I would like to apply:
each of the sub-goals produced by "induction" corresponds to a specific
constructor C, and when I write "econstructor", I really mean "eapply C",
where C is "the constructor associated with the current case".
Is there a way of expressing this in Coq? (I think I see how one could achieve
this by manually duplicating the induction principle, but of course I don't
want to do this.)
Perhaps someone will suggest writing just "eauto" instead of "econstructor;
eauto". Again, in a simple situation, this will work, but I am looking at more
complex situations where 1- I might wish to apply other tactics between
"econstructor" and "eauto"; and 2- reducing the search depth of "eauto" makes
a difference in terms of performance.
Thanks,
--
François Pottier
Francois.Pottier AT inria.fr
http://gallium.inria.fr/~fpottier/
- [Coq-Club] A smarter "induction;econstructor" combo?, Francois Pottier, 05/21/2012
- Re: [Coq-Club] A smarter "induction;econstructor" combo?, Viktor Vafeiadis, 05/21/2012
- Message not available
- Re: [Coq-Club] A smarter "induction;econstructor" combo?, Francois Pottier, 05/22/2012
- Re: [Coq-Club] A smarter "induction;econstructor" combo?, Paolo Herms, 05/22/2012
- Re: [Coq-Club] A smarter "induction;econstructor" combo?, AUGER Cédric, 05/22/2012
- Re: [Coq-Club] A smarter "induction;econstructor" combo?, Pierre Courtieu, 05/23/2012
- Re: [Coq-Club] A smarter "induction;econstructor" combo?, Paolo Herms, 05/23/2012
- Re: [Coq-Club] A smarter "induction;econstructor" combo?, Paolo Herms, 05/22/2012
- Re: [Coq-Club] A smarter "induction;econstructor" combo?, Francois Pottier, 05/22/2012
Archive powered by MHonArc 2.6.18.