Skip to Content.
Sympa Menu

coq-club - Re: [Coq-Club] Equality for inductive type containing list

coq-club AT inria.fr

Subject: The Coq mailing list

List archive

Re: [Coq-Club] Equality for inductive type containing list


Chronological Thread 
  • From: Andrei Popescu <A.Popescu AT mdx.ac.uk>
  • To: Klaus Ostermann <klaus.ostermann AT uni-tuebingen.de>, "coq-club AT inria.fr" <coq-club AT inria.fr>
  • Cc: Jasmin Blanchette <jasmin.blanchette AT inria.fr>, Dmitriy Traytel <traytel AT inf.ethz.ch>
  • Subject: Re: [Coq-Club] Equality for inductive type containing list
  • Date: Mon, 10 Oct 2016 19:34:41 +0000
  • Accept-language: en-GB, en-US
  • Authentication-results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=A.Popescu AT mdx.ac.uk; spf=Neutral smtp.mailfrom=A.Popescu AT mdx.ac.uk; spf=Pass smtp.helo=postmaster AT EUR01-DB5-obe.outbound.protection.outlook.com
  • Ironport-phdr: 9a23:fMEOoBfzj0Xcftb5wrE5/liilGMj4u6mDksu8pMizoh2WeGdxc+4bR7h7PlgxGXEQZ/co6odzbGH6ea7CSdZus/JmUtBWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYsExnyfTB4Ov7yUtaLyZ/mjabpq9aKOFwArQH+SIs6FA+xowTVu5teqqpZAYF19CH0pGBVcf9d32JiKAHbtR/94sCt4MwrqHwI6LoJvvRNWqTifqk+UacQTHF/azh0t4XXskzgSQKS/TM7SXkbiB9BBQ6NuBL+V4rq9Czhqudn3SCcO+XrS7FxRSmv5aZtRxLuzisKYXpxumrQk4l7iL9RiBOnvR12hYDOKsnBP/1nO6jZYNkyRGxbX88XWTYXUa2maI5aJuwNJ+tZ57H6v1YVpgb2USDqPOT3xyRDm1fz0b182u9nDAKQj19oJM4HrHmB9Ia9D6wVS+3gifCQlTg=
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99

Greetings, 


It may be useful to point out how we resolved the problem (mutatis mutandis) in Isabelle/HOL, as discussed in the following papers: 


http://andreipopescu.uk/pdf/LICS2012.pdf 


http://andreipopescu.uk/pdf/codat-impl.pdf


Main idea: Incremental bookkeeping of additional structure for polymorphic types, which replaces the need for guessing the right predicates when nesting.        


For each datatype or codatatype, say, C, polymorphic in n arguments, we store additional information, including on how to lift any predicate from the component types to the type C: 


forall_C : forall U_1 ... U_n : Type. (U_1 -> Prop) -> ... -> (U_n -> Prop) -> C U_1 ... U_n -> Prop


This is essentially the unary relator associated to C. (In Isabelle/HOL, we actually use a different, set-based concept as primitive, but this is not important here.)


This way, a (co)datatype declaration that nests C will know how to induct/recurse through C. For example, if C is polymorphic in one argument, the declaration 


Inductive ty: Set :=
| tvar : id -> ty
| tpoly : id -> C ty -> ty


will produce something like this as an induction principle:


induct 

  forall (P : ty -> Type) 

     (forall x : id. P (tvar x)) 

     (forall x : id, c : C ty. P x -> forall_C P c  -> P (tpoly x c))

     ->

     forall x, P x.  


If C is 'list', then forall_list gives the desired induction principle advocated on this thread. If the defined (co)datatype is itself polymorphic, then it will get its own 'forall' predicate, thus becoming smoothly nestable in further (co)datatypes. 


Please pardon my ignorance with Coq syntax -- I hope the idea is clear though.   


In the mentioned papers, we (like others on this thread) argue that reducing nested (co)datatypes to mutual (co)datatypes is far from ideal. This is because: 


(1) it breaks abstraction


(2) it doesn't scale to more complex nesting, in particular, doesn't work for nesting datatypes in codatatypes or vice versa. 


All the best, 

 Andrei 






Archive powered by MHonArc 2.6.18.

Top of Page