coq-club AT inria.fr
Subject: The Coq mailing list
List archive
- From: Kevin Hamlen <hamlen AT utdallas.edu>
- To: <coq-club AT inria.fr>
- Subject: Re: [Coq-Club] module "best practices"?
- Date: Tue, 21 Aug 2018 13:50:47 -0500
- Authentication-results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=hamlen AT utdallas.edu; spf=Pass smtp.mailfrom=hamlen AT utdallas.edu; spf=None smtp.helo=postmaster AT esa2.hc50-71.r1.ces.cisco.com
- Ironport-phdr: 9a23:w5BHqxedbOPKhhsjlRtoEJdilGMj4u6mDksu8pMizoh2WeGdxcu8YB7h7PlgxGXEQZ/co6odzbaO7Oa4ASQp2tWoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7Ovr6GpLIj8Swyuu+54Dfbx9HiTahY75+Ngm6oRnMvcQKnIVuLbo8xAHUqXVSYeRWwm1oJVOXnxni48q74YBu/SdNtf8/7sBMSar1cbg2QrxeFzQmLns65Nb3uhnZTAuA/WUTX2MLmRdVGQfF7RX6XpDssivms+d2xSeXMdHqQb0yRD+v6bpgRh31hycdLzM37X/ZisJwgqxYrhyuqRNwzIzIb4+aNfpzZb/dcNAASGZdQspcWS5MD4WhZIUPFeoBOuNYopH4qVQQsxu+BA+sD/7txDBSg3/22bM10+I8GgzB3AwvBdcOsHDKo9XzL6oSTPy1w7TSwjXHa/NZwyz95JLWfR88vPGBRLR9etfSx0k3Dw7IjkucpZbqMj6VzOgBrWiW4/d6We6ylWIrsxx9riS1yssxiYTFmJgZx1LY+Slj3Yo4K8G0RFZmbdK6FJZcrTyWO5ZqTs84XW1ltzg2xqcbtZO0fyUHzoksyQTFZPydaYeI5wruVOaPLjd8g3JoYKywhw2o/kS+0OH8VtW73VZWoiZckNTAq2oB1wbO5sSdVvRy4Fyh1SyT2ADS8eFLPUc0mbDHJJ4mx748jpsTsULdES/qgEj7jLGael8r9+Wo8ejrfLXrqoKGO4NplA3yKqEulda+AeQ8PAgORW+b+eGk2b3j50L5RbFKgeMwkqTCrZDaOdkUqbS9Aw9RyIkj8AyzACm739QFhXUHNk5KeAqbj4j1PFHDOOz3DfCmg1i1jDhrw+3GMab6D5XWLnnDla/hcqxn505dzgoz19Ff6IhOBrEPOvKgEnP24YjTCQZ8OAipyc7mDs9838UQQzTcLLWeNfbxvEGJ4KoPKuyIaYld7Db0Lvwo4dbzkXMwnVsUZu+k0YZBOyPwJehvP0jMOSmkudwGC2pf5lNvHtyvs0WLVHtoX1j3Wqs94j8hD4f/UdXeWoykhLiIx2G2EoAEPzkaWGDJKm/hcsC/Y9lJcDibe5MzjyAIXLylQpRn2B2z5lejluhXa9HM8yhdjqrNkdh44+qIzEM/7jUuScSWjjnIEDgyhDpOTDItmqt+ukd6jFyE1Pogjg==
Hi Adam,
Yes, pulling the Inductive definitions out and parameterizing them with type variables is possible. But it can lead to unpleasantly large parameter lists and huge proof contexts. For example, if FOO_TYPE contains 20 parameters, each of which appear individually in constructors of bar, then we're stuck writing 19 extra arguments to each bar-constructor. It gets worse when FOO_TYPE contains Axioms that leak into inductive types as dependently typed parameters. We could, of course, create specialized versions of all the constructors (e.g., barfoo := Bar Foo.foo), but then we get back into the original problem: distinct but equivalent instantiations of FooTheory1 Foo create separate versions of barfoo that don't always unify easily.
What we really want, I think, is a single, centralized definition of Foo.foo that all the FooTheory's share, so that there are never any duplicate names floating around. That seems to jive with Michael's solution: Functors that want to share a definition of Foo.foo should incorporate that definition as part of the Module Type of their module parameters, so that it becomes part of their interfaces.
--Kevin
On 8/21/2018 12:58 PM, Adam Chlipala wrote:
On 08/17/2018 04:36 PM, Kevin Hamlen wrote:
What do Coq programmers consider the "right way" to organize large projects containing functors? In particular, how do authors of large projects define collections of modules that all build upon some shared functor without getting duplicate name-conflicts?
It really seems like a distraction to work so hard to put an inductive definition directly inside a functor body. I would do it like this:
Module Type FOO_TYPE.
Parameter foo: Type.
End FOO_TYPE.
Inductive bar T := Bar (f : T).
Module FooDefs (Foo: FOO_TYPE).
Definition bar := bar Foo.foo.
(* ... hundreds more definitions ... *)
End FooDefs.
Module FooTheory1 (Foo: FOO_TYPE).
Module Import F := FooDefs Foo.
Ltac silly1 := match goal with |- Bar _ _ = Bar _ _ => reflexivity end.
(* ... more theorems, proofs, and ltacs ... *)
End FooTheory1.
Module Foo:FOO_TYPE.
Definition foo:=nat.
End Foo.
Module Import FD := FooDefs Foo.
Module Import FT1 := FooTheory1 Foo.
Theorem silly: forall (x:bar), x=x.
Proof.
destruct x.
silly1.
Qed.
- [Coq-Club] module "best practices"?, Kevin Hamlen, 08/17/2018
- RE: [Coq-Club] module "best practices"?, Soegtrop, Michael, 08/18/2018
- Re: [Coq-Club] module "best practices"?, Samuel Gruetter, 08/18/2018
- RE: [Coq-Club] module "best practices"?, Soegtrop, Michael, 08/19/2018
- Re: [Coq-Club] module "best practices"?, Kevin Hamlen, 08/20/2018
- RE: [Coq-Club] module "best practices"?, Soegtrop, Michael, 08/20/2018
- Re: [Coq-Club] module "best practices"?, Benjamin C. Pierce, 08/20/2018
- RE: [Coq-Club] module "best practices"?, Soegtrop, Michael, 08/23/2018
- Re: [Coq-Club] module "best practices"?, Benjamin C. Pierce, 08/20/2018
- RE: [Coq-Club] module "best practices"?, Soegtrop, Michael, 08/20/2018
- Re: [Coq-Club] module "best practices"?, Kevin Hamlen, 08/20/2018
- RE: [Coq-Club] module "best practices"?, Soegtrop, Michael, 08/19/2018
- Re: [Coq-Club] module "best practices"?, Adam Chlipala, 08/21/2018
- Re: [Coq-Club] module "best practices"?, Kevin Hamlen, 08/21/2018
- Re: [Coq-Club] module "best practices"?, Samuel Gruetter, 08/22/2018
- RE: [Coq-Club] module "best practices"?, Soegtrop, Michael, 08/23/2018
- Re: [Coq-Club] module "best practices"?, David Holland, 08/23/2018
- Re: [Coq-Club] module "best practices"?, Anders Lundstedt, 08/24/2018
- RE: [Coq-Club] module "best practices"?, Soegtrop, Michael, 08/24/2018
- Re: [Coq-Club] module "best practices"?, Anders Lundstedt, 08/24/2018
- Re: [Coq-Club] module "best practices"?, David Holland, 08/23/2018
- RE: [Coq-Club] module "best practices"?, Soegtrop, Michael, 08/23/2018
- Re: [Coq-Club] module "best practices"?, Samuel Gruetter, 08/22/2018
- Re: [Coq-Club] module "best practices"?, Kevin Hamlen, 08/21/2018
Archive powered by MHonArc 2.6.18.