coq-club AT inria.fr
Subject: The Coq mailing list
List archive
- From: Aaron Bohannon <bohannon AT cis.upenn.edu>
- To: Adam Chlipala <adam AT chlipala.net>
- Cc: Coq Club <coq-club AT inria.fr>
- Subject: Re: [Coq-Club] MapsTo in FMapInterface
- Date: Wed, 9 Feb 2011 15:20:50 -0500
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Xbj9ywl96zX+mK26LaEdXZy//d+AiOiXW/9uoz5LbpIkvkogFa9VBEH8vjGrb9oxb+ TPrDQSlWi0bL/CDs3wrBR7hhWWCX1b5xBbiVL/gmr+ofT0yWqHiKQFK4URoxvyJmXs18 4cDP5PJp2OaFrIQsxtvRCXT+EgiF3RpnAJuf8=
Thanks for the quick suggestions. Perhaps the purely brute force
method can be slightly improved like this:
repeat match goal with
| k: _ |- _ =>
progress change MyMap.key in k
end;
repeat match goal with
| k: MyMap.key, v: ?A, m: MyMap.t ?A, H: _ =>
progress change (MyMay.MapsTo k v m) in H
end.
On Wed, Feb 9, 2011 at 3:11 PM, Adam Chlipala
<adam AT chlipala.net>
wrote:
> Aaron Bohannon wrote:
>>
>> I am using FMaps in my development and want to write a tactic that
>> matches hypotheses of the form (MyMap.MapsTo k v m). The problem is
>> that, when I destruct a proposition of the form (MyMap.In k m), I end
>> up with a hypothesis of the form (MyMap.Raw.PX.MapsTo _ _ _). A
>> tactic that matches on (MyMap.MapsTo _ _ _) will not match hypotheses
>> of the form (MyMap.Raw.PX.MapsTo _ _ _). Of course, I can write a
>> tactic that refers directly to MyMap.Raw.PX.MapsTo, but I feel like
>> this is violating the intended abstraction of the FMap interface.
>> Unforunately, the tactic "fold MyMap.MapsTo" does not help because
>> MyMap.MapsTo seems to be defined as an eta-expansion of
>> MyMap.Raw.PX.MapsTo. Any other ideas? Or do I have to write a tactic
>> that breaks the abstraction?
>>
>
> There's a potentially inefficient version that does:
> match goal with
> | [ H : ?f ?a ?b ?c |- _ ] =>
> equate (f a b c) (MyMap.MapsTo a b c); (* use H as planned *)
> end.
>
> ...for some implementation of an equality check [equate], for instance by
> [assert]ing that the two terms are equal, making sure [reflexivity] proves
> it, and then clearing the hypothesis that [assert] added.
>
> (I haven't actually run the above code, so please excuse typos. :])
>
> You may also find that you can ignore this altogether. For instance, if you
> want to do forward reasoning with a theorem [thm] that takes a fact matching
> the hypothesis as its first assumption, you may be able to get away with
> running [apply thm in H] for every hypothesis [H], delegating the matching
> work to unification.
>
- [Coq-Club] MapsTo in FMapInterface, Aaron Bohannon
- Re: [Coq-Club] MapsTo in FMapInterface,
Adam Chlipala
- Re: [Coq-Club] MapsTo in FMapInterface, Aaron Bohannon
- Re: [Coq-Club] MapsTo in FMapInterface,
Aaron Bohannon
- Re: [Coq-Club] MapsTo in FMapInterface, Stéphane Lescuyer
- Re: [Coq-Club] MapsTo in FMapInterface,
Aaron Bohannon
- Re: [Coq-Club] MapsTo in FMapInterface, Aaron Bohannon
- Re: [Coq-Club] MapsTo in FMapInterface,
Adam Chlipala
Archive powered by MhonArc 2.6.16.