From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pA2LF7bO028104 for ; Wed, 2 Nov 2011 22:15:07 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloBAPyxsU7RVaE2kGdsb2JhbABEoX0Bh2wIIgEBAQEJCQ0HFAQhgXIBAQEDARICLAEbHgMBCwYQBgMBAgEuIQEBEQEFARICCBkih2CXbQqLVIJghVc9iHACBQqJBgSIB4wNijuCfj2EDg X-IronPort-AV: E=Sophos;i="4.69,445,1315173600"; d="scan'208";a="127831477" Received: from mail-fx0-f54.google.com ([209.85.161.54]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 02 Nov 2011 22:15:01 +0100 Received: by faar19 with SMTP id r19so1679979faa.27 for ; Wed, 02 Nov 2011 14:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yJ6ooqNfpkq6gLKveDKyOoxXAy0gc9i7RrpJLVEP2Ek=; b=iblImRAZfof0E9DN6YeHJZT2x4FgXn9G8kgPBwU2OM+Adg3AoskfJMBxM+qaQwjaDI qivvy6bZGITbIbJqvrqencSVRPhESx+raPuCTHbtioyfg9Dc9lYsL59O4ppEEKwNPfCg YlbWGaYXBfHOqTGloP6NEVSMwxco7c6/cyszA= MIME-Version: 1.0 Received: by 10.223.94.143 with SMTP id z15mr6896323fam.32.1320268481809; Wed, 02 Nov 2011 14:14:41 -0700 (PDT) Received: by 10.152.6.227 with HTTP; Wed, 2 Nov 2011 14:14:41 -0700 (PDT) In-Reply-To: References: <4EB1A5DB.8070405@gmail.com> Date: Wed, 2 Nov 2011 15:14:41 -0600 Message-ID: From: Anthony Tavener To: caml-list@inria.fr Content-Type: multipart/alternative; boundary=001517478f1addcd9c04b0c6f5e2 Subject: Fwd: [Caml-list] Nested module exposing type from parent? --001517478f1addcd9c04b0c6f5e2 Content-Type: text/plain; charset=ISO-8859-1 Oops, I didn't do a group-reply... so in case anyone is interested in what I ended up with: ---------- Forwarded message ---------- From: Anthony Tavener Date: Wed, Nov 2, 2011 at 2:50 PM Subject: Re: [Caml-list] Nested module exposing type from parent? To: Vincent Aravantinos Actually, better than I initially thought... I keep this as I have them defined already, except as you said: include instead of open. module Vec = struct module Type = struct type t = { x: int; y: int } end include Type let make x y = {x;y} let add a b = {x=a.x+b.x; y=a.y+b.y} end Before, I had instead of the include: type t = Type.t open Type Which worked, but then the type used everywhere was Vec.Type.t Thanks again! Simple and effective, and I was looking in all the wrong places. :) On Wed, Nov 2, 2011 at 2:36 PM, Anthony Tavener wrote: > Thank-you Vincent! > > Though this requires a home for the "source type" module, at least the > types come out right in the end. Thanks! > > And this led me to read specifically about include to understand what it > really does. :) > > > On Wed, Nov 2, 2011 at 2:19 PM, Vincent Aravantinos < > vincent.aravantinos@gmail.com> wrote: > >> ** >> Using "include" instead of "open" would work, ie. turning your example >> into: >> >> module Vec_main = struct >> >> type t = { x: int; y: int } >> let make x y = {x;y} >> let add a b = {x=a.x+b.x; y=a.y+b.y} >> end >> >> module Vec = struct >> include Vec_main >> module Type = struct >> include Vec_main >> ... >> end >> end >> >> Then: >> # let n = Vec.make 2 5;; >> val n : Vec.t = {Vec.x = 2; Vec.y = 5} >> # open Vec.Type;; >> # let m = {x=1;y=2};; >> val m : Vec.Type.t = {x = 1; y = 2} >> # Vec.add m n;; >> - : Vec.t = {Vec.x = 3; Vec.y = 7} >> >> Cheers >> >> -- >> Vincent Aravantinos - Postdoctoral Fellow, Concordia University, Hardware Verification Group >> >> >> On 11/02/2011 03:41 PM, Anthony Tavener wrote: >> >> I've been struggling with this occasionally... >> >> I'm using nested modules to "open" access to select features of a >> module. My problem is I can't find a way to *expose* types in the parent >> module through such nested modules. >> >> A simplified example of what I'm looking at: >> >> module Vec = struct >> >> type t = { x: int; y: int } >> let make x y = {x;y} >> let add a b = {x=a.x+b.x; y=a.y+b.y} >> >> module Type = >> (* something which has type t = Vec.t, >> * with exposed structure when "open"ed. >> * Also note that Vec is not really an >> * explicit module like this; instead it >> * is implemented in vec.ml *) >> end >> >> Example usage... >> >> let n = Vec.make 2 5 >> open Vec.Type >> let m = {x=1;y=2} >> Vec.add m n >> >> >> To date, I've defined the type in the Type submodule, which is then >> used by the parent module. The unsatisfactory quality of this is that >> Vec.Type.t is the "true" type. Ideally the concrete type would live at >> Vec.t, with "open Vec.Type" bringing the fields of the type into scope. >> >> As background, here are examples of opening different features of the >> Vec module: >> >> let c = Vec.add a b >> >> open Vec.Prefixed >> let c = vadd a b >> >> open Vec.Ops >> let c = a +| b >> >> open Vec.Type >> let c = Vec.add a {x;y;z=0.} >> >> Apologies if this is really beginner-list material. It's minor, but has >> been bugging me. >> Thank-you for looking, >> >> Tony >> >> >> > --001517478f1addcd9c04b0c6f5e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Oops, I didn't do a group-reply... so in case anyone is interested in w= hat I ended up with:

---------- Forwarded= message ----------
From: Anthony Tavener<= /b> <anth= ony.tavener@gmail.com>
Date: Wed, Nov 2, 2011 at 2:50 PM
Subject: Re: [Caml-list] Nested module= exposing type from parent?
To: Vincent Aravantinos <vincent.aravantinos@gmail.com>


Actually, better than I initially thought...

I k= eep this as I have them defined already, except as you said: include instea= d of open.

=A0 module Vec =3D struct
=A0 =A0 module Type =3D struct
=A0 =A0 =A0 type t =3D { x: int; y: int }
=A0 =A0 end<= /div>
=A0 =A0 include Type
=A0 =A0 let make= x y =3D {x;y}
=A0 =A0 let add a b =3D {x=3Da.x+b.x; y=3Da.y+b.y}=
=A0 end

Before, I had instead of the include:
=A0 type t =3D Type.t
=A0 open Type
Which worked, but then the type used everywhere was Vec.Type.t<= /div>

Thanks again! Simple and effective, an= d I was looking in all the wrong places. :)

On = Wed, Nov 2, 2011 at 2:36 PM, Anthony Tavener <anthony.tavener@gma= il.com> wrote:
Thank-you Vincent!

Though= this requires a home for the "source type" module, at least the = types come out right in the end. Thanks!

And this led me to read specifically about include to u= nderstand what it really does. :)


On Wed, Nov 2, 2011 at 2:19 PM, Vin= cent Aravantinos <vincent.aravantinos@gmail.com>= wrote:
=20=20 =20=20=20=20 =20=20
Using "include" instead of "open" would work, ie. t= urning your example into:

module Vec_main =3D struct

=A0 type t =3D { x: int; y: int }
=A0 let make x y =3D {x;y}
=A0 let add a b =3D {x=3Da.x+b.x; y=3Da.y+b.y}
end

module Vec =3D struct
=A0 include Vec_main
=A0 module Type =3D struct
=A0=A0=A0 include Vec_main
=A0=A0=A0 ...
=A0 end
end

Then:
# let n =3D Vec.make 2 5;;
val n : Vec.t =3D {Vec.x =3D 2; Vec.y =3D 5}
# open Vec.Type;;
# let m =3D {x=3D1;y=3D2};;
val m : Vec.Type.t =3D {x =3D 1; y =3D 2}
# Vec.add m n;;
- : Vec.t =3D {Vec.x =3D 3; Vec.y =3D 7}

Cheers

--=20
Vincent Aravantinos - Postdoctoral Fellow, Concordia University, Hardware V=
erification Group

On 11/02/2011 03:41 PM, Anthony Tavener wrote:
I've been struggling with this occasionally...

I'm using nested modules to "open" access to selec= t features of a module. My problem is I can't find a way to *expose* types in the parent module through such nested modules.

A simplified example of what I'm looking at:

=A0 module Vec =3D struct

=A0 =A0 type t =3D { x: int; y: int }
=A0 =A0 let make x y =3D {x;y}
=A0 =A0 let add a b =3D {x=3Da.x+b.x; y=3Da.y+b.y}

=A0 =A0 module Type =3D
=A0 =A0 =A0 (* something which has type t =3D Vec.t,
=A0 =A0 =A0 =A0* with exposed structure when "open"ed.=
=A0 =A0 =A0 =A0* Also note that Vec is not really an
=A0 =A0 =A0 =A0* explicit module like this; instead it
=A0 =A0 =A0 =A0* is implemented in vec.ml *)
=A0 end

Example usage...

=A0 let n =3D Vec.make 2 5
=A0 open Vec.Type
=A0 let m =3D {x=3D1;y=3D2}
=A0 Vec.add m n


To date, I've defined the type in the Type submodule, which is then used by the parent module. The unsatisfactory quality of this is that Vec.Type.t is the "true" type. Ideally the c= oncrete type would live at Vec.t, with "open Vec.Type" bringing t= he fields of the type into scope.

As background, here are examples of opening different features of the Vec module:

=A0 let c =3D Vec.add a b

=A0 open Vec.Prefixed
=A0 let c =3D vadd a b

=A0 open Vec.Ops
=A0 let c =3D a +| b

=A0 open Vec.Type
=A0 let c =3D Vec.add a {x;y;z=3D0.}

Apologies if this is really beginner-list material. It's minor, but has been bugging me.
Thank-you for looking,

=A0Tony





--001517478f1addcd9c04b0c6f5e2--