Skip to Content.
Sympa Menu

coq-club - Re: [Coq-Club] Sigma-types and modules

coq-club AT inria.fr

Subject: The Coq mailing list

List archive

Re: [Coq-Club] Sigma-types and modules


Chronological Thread 
  • From: Saulo Araujo <saulo2 AT gmail.com>
  • To: coq-club AT inria.fr
  • Subject: Re: [Coq-Club] Sigma-types and modules
  • Date: Mon, 27 Jun 2016 15:30:32 -0300
  • Authentication-results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=saulo2 AT gmail.com; spf=Pass smtp.mailfrom=saulo2 AT gmail.com; spf=None smtp.helo=postmaster AT mail-it0-f46.google.com
  • Ironport-phdr: 9a23:c+KZNBQFlFFNcXgUs6r//6xor9psv+yvbD5Q0YIujvd0So/mwa64ZhyN2/xhgRfzUJnB7Loc0qyN4vimADVLuMzZ+Fk5M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aJBzzOEJPK/jvHcaK1oLshrj0osSYOl8QzBOGIppKZC2sqgvQssREyaBDEY0WjiXzn31TZu5NznlpL1/A1zz158O34YIxu38I46FppIZ8VvDxeL19RrhFBhwnNXo07Yvlr0rtVwyKs0AVT2ER2jNSChXH61muRZ7stiygnuV40Siee8bxSOZnCnyZ8653RUqw2288PDkj/TSPhw==

Hi Cedric,

I became interested in modules because they seemed to be the "official" way of separating the interface of a component from its implementations, similar to what one accomplishes in Java with interfaces and classes. Thanks for pointing raw records and type classes as alternatives do modules. After studying modules a little more, I am gonna look into your suggestions.

Sincerely,
Saulo

On Mon, Jun 27, 2016 at 2:16 PM, Cedric Auger <sedrikov AT gmail.com> wrote:


2016-06-27 2:32 GMT+02:00 Saulo Araujo <saulo2 AT gmail.com>:
Hi,

I am starting to study modules in Coq and I have a doubt regarding modules and sigma types. I have defined the module signature TotalMap, which is very similar to the one found in the book Interactive Theorem Proving and Software Development:

Module Type TotalMap.

Parameter Key: Set.

Parameter Value: Set.

Parameter TotalMap: Set.

Parameter get: TotalMap -> Key -> Value.

Parameter put: TotalMap -> Key -> Value -> TotalMap.

Axiom putMapsKeyToValue: forall (p: TotalMap) (k: Key) (v: Value), get (put p k v) k = v.

Axiom putRetainsOtherMappings: forall (p: TotalMap) (k1 k2: Key) (v: Value), k1 <> k2 -> get (put p k1 v) k2 = get p k2.

End TotalMap.

Now, I want to create an implementation called CompleteBinaryLeafTree, in which the parameter Key is the sigma-type {ds: list bool | length ds = n}, where n is a nat. I have tried to declare CompleteBinaryLeafTree as below:

Module CompleteBinaryLeafTree: TotalMap with Definition Key := {ds: list bool | length ds = n}.

but, of course, Coq complains about not knowing what is n.

I also have tried to declare CompleteBinaryLeafTree as a functor from nat to TotalMap:

Module CompleteBinaryLeafTree (n: nat): TotalMap with Definition Key := {ds: list bool | length ds = n}.

But Coq complains that nat is not a module.

I had success creating an "articial" module signature called NatContainer:

Module Type NatContainer.

Parameter n: nat.

End NatContainer.

and declaring CompleteBinaryLeafTree as a functor from NatContainer to TotalMap:

​​
Module CompleteBinaryLeafTree (c: NatContainer): TotalMap with Definition Key := {ds: list bool | length ds = c.n}.

Is there a "less artificial" way of creating an implementation of TotalMap, in which Key is the sigma-type {ds: list bool | length ds = c.n}?

Sincerely,
Saulo Araujo

​The first thing is to wonder if you really need modules.
Modules in Coq are often more cumbersome than raw records (or type classes), and can almost always be replaced by them.
If you really need them (for instance, because you use a library not designed to support other things than modules)​
 
​,
then you can try to make CompleteBinaryLeafTree live in a world where nat is already defined.
Something like

Parameter n:nat.​
Module CompleteBinaryLeafTree : TotalMap with Definition Key := {ds: list bool | length ds = n}.​

should work (but your n will be fixed, you cannot have various CompleteBinaryLeafTree with different values of n).




Archive powered by MHonArc 2.6.18.

Top of Page