Skip to Content.
Sympa Menu

coq-club - Re: [Coq-Club] Breaking typeclass instance cycles

coq-club AT inria.fr

Subject: The Coq mailing list

List archive

Re: [Coq-Club] Breaking typeclass instance cycles


chronological Thread 
  • From: Tom Prince <tom.prince AT ualberta.net>
  • To: Matthieu Sozeau <matthieu.sozeau AT gmail.com>
  • Cc: Daniel Schepler <dschepler AT gmail.com>, Robbert Krebbers <mail AT robbertkrebbers.nl>, Coq Club <coq-club AT inria.fr>
  • Subject: Re: [Coq-Club] Breaking typeclass instance cycles
  • Date: Sat, 07 May 2011 01:04:18 -0400

On 2011-05-06, Matthieu Sozeau wrote:
> > Class Arrows (O: Type): Type := Arrow: O → O → Type.
> > Instance flipA {Object} {A: Arrows Object}: Arrows Object := flip A.
> > CoInductive dual_arrows_done (T: Type) : Prop := did_dual_arrows.         
> >                
> > Hint Extern 100 (Arrows ?x) => match goal with                            
> >                
> >                                 | _ : dual_arrows_done x |- _ => fail 1   
> >               
> >                                 | |- _ => let H:=fresh "H" in set 
> > (H:=did_dual_arrows x); class_apply @flipA
> >                               end : typeclass_instances.  
> > 
> 
>   There is no way to tell if a flipA should be triggerd here, is there? 
> If you had a dummy [flipObject] definition to act as an index you could 
> control its application using an [Arrows (flipObject ?x)] pattern, but
> I guess you don't want that.

Well, I am not sure I have all the permutations, but I think I can
describe when it should be applied.
1) If we have already tried to apply other instances
*and*
2) We are not deducing the argument of flipA. (in particular, when the
outer flipA is provided by the user, not deduced.

It is a subtle thing, though, since adding the above hint also leads to
cycles caused by the instances defined in terms of flipA, that I haven't
figured out yet.

  Tom




Archive powered by MhonArc 2.6.16.

Top of Page