From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 1368B7FACB for ; Fri, 5 Sep 2014 03:39:39 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of yotambarnoy@gmail.com) identity=pra; client-ip=209.85.192.49; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of yotambarnoy@gmail.com designates 209.85.192.49 as permitted sender) identity=mailfrom; client-ip=209.85.192.49; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-qg0-f49.google.com) identity=helo; client-ip=209.85.192.49; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-qg0-f49.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgBAGITCVTRVcAxlGdsb2JhbABZg2BXBIJ4xTiHTAGBAQgWEAEBAQEHCwsJEiuEAwEBAQMBEhEEGQEbHgMBCwYFCw0qAgIhAQERAQUBHAYTIogLAQMJCA2bY2uLK4FygxCJIQoZJw1mhXQBEQEBBA6NEoIpC4J5gVMFjymGRYRughCOaoRGGCmFLiEvgk8BAQE X-IPAS-Result: ApgBAGITCVTRVcAxlGdsb2JhbABZg2BXBIJ4xTiHTAGBAQgWEAEBAQEHCwsJEiuEAwEBAQMBEhEEGQEbHgMBCwYFCw0qAgIhAQERAQUBHAYTIogLAQMJCA2bY2uLK4FygxCJIQoZJw1mhXQBEQEBBA6NEoIpC4J5gVMFjymGRYRughCOaoRGGCmFLiEvgk8BAQE X-IronPort-AV: E=Sophos;i="5.04,470,1406584800"; d="scan'208";a="93098357" Received: from mail-qg0-f49.google.com ([209.85.192.49]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 05 Sep 2014 03:39:38 +0200 Received: by mail-qg0-f49.google.com with SMTP id j107so10851756qga.22 for ; Thu, 04 Sep 2014 18:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=2SDCZhgl52MB1e5dh8+n4NWQ9yw7aDU96ula2TtJUuY=; b=a7M9Df5dtcZ1E7ZKWO0mJy9bqU+VAThDkJEZ6YtgxclWuhClIZj/z4+sztL7oU0aFC /lu6GQbonkT3La6qj+fmaDvyq4/hl5aOBC+yWXngiF0bYuXTlXkT5HUipVTCRijb40oo kGQ6ghGz9Kl95uAZsd74K9nAY7JtFSfAi2FVXUoQEHhGz/m/1xxwbZLK5gCy5QSB4U9V klfLfyBvWu2WvPuEcTugSrLpJHWIHa2+mNIPSz32/CqNj4rjgyJhvFQ757fazwJsPCdd DJjhDEpKtQD37UL1g2w1qe/6TFWK8IrRXruWvxBipnuRmhvS4J0KS9O7TONsujmcgG+0 /n4w== X-Received: by 10.140.38.73 with SMTP id s67mr13268472qgs.4.1409881177138; Thu, 04 Sep 2014 18:39:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.174.68 with HTTP; Thu, 4 Sep 2014 18:39:17 -0700 (PDT) In-Reply-To: References: From: Yotam Barnoy Date: Thu, 4 Sep 2014 21:39:17 -0400 Message-ID: To: Ocaml Mailing List Content-Type: multipart/alternative; boundary=001a11c1274cbd2e530502478aa8 Subject: Re: [Caml-list] help with functors --001a11c1274cbd2e530502478aa8 Content-Type: text/plain; charset=UTF-8 I've created a gist at https://gist.github.com/anonymous/cbfe96b920f08208e1dc to illustrate the problem. I can't get InnerBag to unify with the ValueBag. This is a very sparse representation of the code, but it contains all the essential elements in one file, so you can just try to build it with ocamlc. Thanks in advance Yotam On Thu, Sep 4, 2014 at 5:59 PM, Yotam Barnoy wrote: > Thanks for the reply Gabriel. I can't post the code at this time -- not > without leaving out a whole bunch of it, in which case getting it to > compile will be difficult. The pattern should be clear enough, though: > ocaml uses functors for all complex persistent data structures, and if I > have a Map.Make(something), and then another functorized module that > contains Map.Make(something), there should be a way to unify the outer and > inner Map. That's basically my situation, but ocaml refuses to unify the > two Map applications. > > Also, there are also very few resources online about complex uses of > functors. Almost every resource touches trivial uses and then moves on to > other subjects. > > > On Thu, Sep 4, 2014 at 11:12 AM, Gabriel Scherer < > gabriel.scherer@gmail.com> wrote: > >> (voluntarily private reply) >> >> Could you send a self-contained source code that can be compiled (.. and >> maybe raise a type error)? Your code above is good but there are ellipsis >> that people maybe don't want to have to fill themselves to experiment with >> your problem. >> >> >> On Thu, Sep 4, 2014 at 3:53 PM, Yotam Barnoy >> wrote: >> >>> Here's an attempt to clarify the question: >>> >>> I have a functor F and a functor G. I apply F to module M outside of G >>> to create F', and within G I also apply F to M to create F''. Additionally, >>> G is applied to M to create G'. How do I make the compiler understand that >>> F' outside G' is the same as F'' inside G'? >>> >>> Yotam >>> >>> >>> On Wed, Sep 3, 2014 at 1:20 PM, Yotam Barnoy >>> wrote: >>> >>>> Working with ocaml's functional data structures has quickly become a >>>> job of connecting different functors together, and I'd appreciate some help. >>>> >>>> I have the following layout: >>>> >>>> module rec OrderedKey : OrderedKeyType = struct >>>> type t = Value.value_t >>>> let compare = compare >>>> let filter_idxs idxs = function >>>> | Value.VTuple l -> Value.VTuple(list_filter_idxs idxs l) >>>> | _ -> invalid_arg "not a vtuple" >>>> end >>>> >>>> and ValueBag : IBag.S with type elt = Value.value_t = >>>> IBag.Make(OrderedKey) >>>> >>>> and ValueMMap : IMultimap.S with type elt = Value.value_t and type bag >>>> = ValueBag.t = >>>> IMultimap.Make(OrderedKey) >>>> >>>> and Value : sig ... type value_t = ... end = Value >>>> >>>> The situation is as such: my multimap (IMultimap) contains an internal >>>> specialization of the IBag functor called an InnerBag. It attempts to >>>> return said bag, which is equivalent to the external ValueBag in structure. >>>> However, I don't know how to tell ocaml that the type 'bag' which is >>>> abstract in IMultimap is exactly the same as the external ValueBag. I tried >>>> to do that above, but what I get is a mismatch between IMultimap's internal >>>> InnerBag.t and the external ValueBag.t. >>>> >>>> Any help would be appreciated. >>>> >>>> Yotam >>>> >>>> >>> >> > --001a11c1274cbd2e530502478aa8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've created a gist at https://gist.github.com/anony= mous/cbfe96b920f08208e1dc to illustrate the problem. I can't get=C2= =A0 InnerBag to unify with the ValueBag. This is a very sparse representati= on of the code, but it contains all the essential elements in one file, so = you can just try to build it with ocamlc.

Thanks in advance
Yotam


On Thu, Sep 4, 2014 at 5:59 PM, Yota= m Barnoy <yotambarnoy@gmail.com> wrote:
Thanks for the reply Gabrie= l. I can't post the code at this time -- not without leaving out a whol= e bunch of it, in which case getting it to compile will be difficult. The p= attern should be clear enough, though: ocaml uses functors for all complex = persistent data structures, and if I have a Map.Make(something), and then a= nother functorized module that contains Map.Make(something), there should b= e a way to unify the outer and inner Map. That's basically my situation= , but ocaml refuses to unify the two Map applications.

Also, there are also very few resources online about complex uses of fu= nctors. Almost every resource touches trivial uses and then moves on to oth= er subjects.


On Thu, Sep 4, 2014 at 11:12 AM, Gabriel Scherer <gabriel.scherer@= gmail.com> wrote:
(voluntarily private reply)

Could you s= end a self-contained source code that can be compiled (.. and maybe raise a= type error)? Your code above is good but there are ellipsis that people ma= ybe don't want to have to fill themselves to experiment with your probl= em.


On Thu, Sep 4, 2014 at 3:53 PM, Yotam Barnoy <yotambarnoy@gmail.com= > wrote:
Here's an attempt to cl= arify the question:

I have a functor F and a functor G. = I apply F to module M outside of G to create F', and within G I also ap= ply F to M to create F''. Additionally, G is applied to M to create= G'. How do I make the compiler understand that F' outside G' i= s the same as F'' inside G'?

Yotam


On Wed, Sep 3, 2014 at 1:20= PM, Yotam Barnoy <yotambarnoy@gmail.com> wrote:
Working with ocaml's fu= nctional data structures has quickly become a job of connecting different f= unctors together, and I'd appreciate some help.

I have the following layout:

module rec OrderedKey : OrderedKeyType =3D struct<= /div>
=C2=A0 =C2=A0 type t =3D Value.value_t
=C2=A0 =C2=A0 le= t compare =3D compare
=C2=A0 =C2=A0 let filter_idxs idxs =3D func= tion
=C2=A0 =C2=A0 =C2=A0 | Value.VTuple l -> Value.VTuple(lis= t_filter_idxs idxs l)
=C2=A0 =C2=A0 =C2=A0 | _ -> invalid_arg "not a vtuple"
=C2=A0 =C2=A0 end

and ValueBag : IBag.S wi= th type elt =3D Value.value_t =3D
=C2=A0 IBag.Make(OrderedKey)

and ValueMMap : IMultimap.S with type elt =3D Value.= value_t and type bag =3D ValueBag.t =3D
=C2=A0 IMultimap.Make(OrderedKey)

and Value := sig ... type value_t =3D ... end =3D Value

= The situation is as such: my multimap (IMultimap) contains an internal spec= ialization of the IBag functor called an InnerBag. It attempts to return sa= id bag, which is equivalent to the external ValueBag in structure. However,= I don't know how to tell ocaml that the type 'bag' which is ab= stract in IMultimap is exactly the same as the external ValueBag. I tried t= o do that above, but what I get is a mismatch between IMultimap's inter= nal InnerBag.t and the external ValueBag.t.

Any help would be appreciated.

Yotam




--001a11c1274cbd2e530502478aa8--