* [Caml-list] "module type of" on sub-module of functor result @ 2012-02-21 18:16 Ashish Agarwal 2012-02-21 19:37 ` [Caml-list] " Ashish Agarwal 0 siblings, 1 reply; 12+ messages in thread From: Ashish Agarwal @ 2012-02-21 18:16 UTC (permalink / raw) To: Caml List [-- Attachment #1: Type: text/plain, Size: 581 bytes --] The following code compiles correctly: ----- a.ml ----- open Batteries module Ord = struct type t=string let compare=compare end module type S = sig include module type of Map.Make(Ord) (* include module type of Map.Make(Ord).Labels *) end ----- An easy workaround is to name the functor's result: ----- a.ml ----- open Batteries module Ord = struct type t=string let compare=compare end module M = Map.Make(Ord) module type S = sig include module type of M include module type of M.Labels end ----- The above compiles correctly, but is this the best/only solution? [-- Attachment #2: Type: text/html, Size: 981 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Caml-list] Re: "module type of" on sub-module of functor result 2012-02-21 18:16 [Caml-list] "module type of" on sub-module of functor result Ashish Agarwal @ 2012-02-21 19:37 ` Ashish Agarwal 2012-02-21 20:32 ` Hezekiah M. Carty 0 siblings, 1 reply; 12+ messages in thread From: Ashish Agarwal @ 2012-02-21 19:37 UTC (permalink / raw) To: Caml List [-- Attachment #1: Type: text/plain, Size: 1187 bytes --] I must've accidentally deleted part of my email before hitting send. The point was to make the first code sample compile after removing the commented line. But that is not allowed; I get a syntax error: $ ocamlfind ocamlc -c -package batteries a.ml File "a.ml", line 6, characters 38-39: Error: Syntax error: 'end' expected File "a.ml", line 4, characters 16-19: Error: This 'sig' might be unmatched I'm wondering if there is a better solution than my second code sample. On Tue, Feb 21, 2012 at 1:16 PM, Ashish Agarwal <agarwal1975@gmail.com>wrote: > The following code compiles correctly: > > ----- a.ml ----- > open Batteries > module Ord = struct type t=string let compare=compare end > > module type S = sig > include module type of Map.Make(Ord) > (* include module type of Map.Make(Ord).Labels *) > end > ----- > > An easy workaround is to name the functor's result: > > ----- a.ml ----- > open Batteries > module Ord = struct type t=string let compare=compare end > > module M = Map.Make(Ord) > > module type S = sig > include module type of M > include module type of M.Labels > end > ----- > > The above compiles correctly, but is this the best/only solution? > > [-- Attachment #2: Type: text/html, Size: 2057 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Caml-list] Re: "module type of" on sub-module of functor result 2012-02-21 19:37 ` [Caml-list] " Ashish Agarwal @ 2012-02-21 20:32 ` Hezekiah M. Carty 2012-02-22 16:18 ` Milan Stanojević 0 siblings, 1 reply; 12+ messages in thread From: Hezekiah M. Carty @ 2012-02-21 20:32 UTC (permalink / raw) To: Ashish Agarwal; +Cc: Caml List On Tue, Feb 21, 2012 at 2:37 PM, Ashish Agarwal <agarwal1975@gmail.com> wrote: > I must've accidentally deleted part of my email before hitting send. The > point was to make the first code sample compile after removing the commented > line. But that is not allowed; I get a syntax error: > > $ ocamlfind ocamlc -c -package batteries a.ml > File "a.ml", line 6, characters 38-39: > Error: Syntax error: 'end' expected > File "a.ml", line 4, characters 16-19: > Error: This 'sig' might be unmatched > > I'm wondering if there is a better solution than my second code sample. > I use this quite often. Your first example is close: ---- a.ml ---- open Batteries module Ord = struct type t=string let compare=compare end module type S = sig include module type of Map.Make(Ord) (* You do not need the Map.Make(Ord) prefix *) include module type of Labels end ---- That works for me on OCaml 3.12.1 with Batteries 1.4.1. Hez ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Caml-list] Re: "module type of" on sub-module of functor result 2012-02-21 20:32 ` Hezekiah M. Carty @ 2012-02-22 16:18 ` Milan Stanojević 2012-02-22 16:40 ` Till Varoquaux 0 siblings, 1 reply; 12+ messages in thread From: Milan Stanojević @ 2012-02-22 16:18 UTC (permalink / raw) To: Hezekiah M. Carty; +Cc: Ashish Agarwal, Caml List On Tue, Feb 21, 2012 at 3:32 PM, Hezekiah M. Carty <hez@0ok.org> wrote: > On Tue, Feb 21, 2012 at 2:37 PM, Ashish Agarwal <agarwal1975@gmail.com> wrote: >> I must've accidentally deleted part of my email before hitting send. The >> point was to make the first code sample compile after removing the commented >> line. But that is not allowed; I get a syntax error: >> >> $ ocamlfind ocamlc -c -package batteries a.ml >> File "a.ml", line 6, characters 38-39: >> Error: Syntax error: 'end' expected >> File "a.ml", line 4, characters 16-19: >> Error: This 'sig' might be unmatched >> >> I'm wondering if there is a better solution than my second code sample. >> I would consider this a bug. I think than any module expression than can be used with "include" should be usable with "include module type of" ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Caml-list] Re: "module type of" on sub-module of functor result 2012-02-22 16:18 ` Milan Stanojević @ 2012-02-22 16:40 ` Till Varoquaux 2012-02-22 17:24 ` Gabriel Scherer 2012-02-22 17:35 ` Ashish Agarwal 0 siblings, 2 replies; 12+ messages in thread From: Till Varoquaux @ 2012-02-22 16:40 UTC (permalink / raw) To: Milan Stanojević; +Cc: Hezekiah M. Carty, Ashish Agarwal, Caml List 2012/2/22 Milan Stanojević <milanst@gmail.com>d > On Tue, Feb 21, 2012 at 3:32 PM, Hezekiah M. Carty <hez@0ok.org> wrote: >> On Tue, Feb 21, 2012 at 2:37 PM, Ashish Agarwal <agarwal1975@gmail.com> wrote: >>> I must've accidentally deleted part of my email before hitting send. The >>> point was to make the first code sample compile after removing the commented >>> line. But that is not allowed; I get a syntax error: >>> >>> $ ocamlfind ocamlc -c -package batteries a.ml >>> File "a.ml", line 6, characters 38-39: >>> Error: Syntax error: 'end' expected >>> File "a.ml", line 4, characters 16-19: >>> Error: This 'sig' might be unmatched >>> >>> I'm wondering if there is a better solution than my second code sample. >>> > > I would consider this a bug. I think than any module expression than > can be used with "include" should be usable with "include module type > of" > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > Milan is right: the language grammar does say that both [include] and [module type of] should work on module_expr. However, based upon the manual(*), [A(B)] and [A.B] are syntacticly valid module_expr's but [A(B).C] isn't. Is this because of an inherent limitation in the module system? [*]http://caml.inria.fr/pub/docs/manual-ocaml/manual019.html#module-expr ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Caml-list] Re: "module type of" on sub-module of functor result 2012-02-22 16:40 ` Till Varoquaux @ 2012-02-22 17:24 ` Gabriel Scherer 2012-02-22 18:49 ` Andreas Rossberg 2012-02-22 17:35 ` Ashish Agarwal 1 sibling, 1 reply; 12+ messages in thread From: Gabriel Scherer @ 2012-02-22 17:24 UTC (permalink / raw) To: Till Varoquaux Cc: Milan Stanojević, Hezekiah M. Carty, Ashish Agarwal, Caml List > [A(B)] and [A.B] are syntacticly valid module_expr's but > [A(B).C] isn't. Is this because of an inherent limitation in the > module system? I believe so. When you apply a functor, you may get fresh types as a result -- the generative (abstract, algebraic) types of the functor image. If you write `module M = A(B)`, the fresh types have a clear identity: M.t, M.q etc; similarly if you pass A(B) to a functor with formal parameter X, it is X.t, X.q etc. But if you write `module M = A(B).C`, there is no syntactic way to name the fresh types generated by the functor application; in particular, naming them A(B).t would be incorrect -- because you could mix types of different applications. For example, what would be the signature of A(B).C with: module B = struct end module A(X : sig end) = struct type t module C = struct type q = t end end ? 2012/2/22 Till Varoquaux <till@pps.jussieu.fr>: > 2012/2/22 Milan Stanojević <milanst@gmail.com>d >> On Tue, Feb 21, 2012 at 3:32 PM, Hezekiah M. Carty <hez@0ok.org> wrote: >>> On Tue, Feb 21, 2012 at 2:37 PM, Ashish Agarwal <agarwal1975@gmail.com> wrote: >>>> I must've accidentally deleted part of my email before hitting send. The >>>> point was to make the first code sample compile after removing the commented >>>> line. But that is not allowed; I get a syntax error: >>>> >>>> $ ocamlfind ocamlc -c -package batteries a.ml >>>> File "a.ml", line 6, characters 38-39: >>>> Error: Syntax error: 'end' expected >>>> File "a.ml", line 4, characters 16-19: >>>> Error: This 'sig' might be unmatched >>>> >>>> I'm wondering if there is a better solution than my second code sample. >>>> >> >> I would consider this a bug. I think than any module expression than >> can be used with "include" should be usable with "include module type >> of" >> >> -- >> Caml-list mailing list. Subscription management and archives: >> https://sympa-roc.inria.fr/wws/info/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs >> > > Milan is right: the language grammar does say that both [include] and > [module type of] should work on module_expr. However, based upon the > manual(*), [A(B)] and [A.B] are syntacticly valid module_expr's but > [A(B).C] isn't. Is this because of an inherent limitation in the > module system? > > [*]http://caml.inria.fr/pub/docs/manual-ocaml/manual019.html#module-expr > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Caml-list] Re: "module type of" on sub-module of functor result 2012-02-22 17:24 ` Gabriel Scherer @ 2012-02-22 18:49 ` Andreas Rossberg 2012-02-22 23:17 ` Jacques Garrigue 0 siblings, 1 reply; 12+ messages in thread From: Andreas Rossberg @ 2012-02-22 18:49 UTC (permalink / raw) To: Gabriel Scherer; +Cc: caml List On Feb 22, 2012, at 18.24 h, Gabriel Scherer wrote: >> [A(B)] and [A.B] are syntacticly valid module_expr's but >> [A(B).C] isn't. Is this because of an inherent limitation in the >> module system? > > I believe so. When you apply a functor, you may get fresh types as a > result -- the generative (abstract, algebraic) types of the functor > image. If you write `module M = A(B)`, the fresh types have a clear > identity: M.t, M.q etc; similarly if you pass A(B) to a functor with > formal parameter X, it is X.t, X.q etc. But if you write `module M = > A(B).C`, there is no syntactic way to name the fresh types generated > by the functor application; in particular, naming them A(B).t would be > incorrect -- because you could mix types of different applications. > > For example, what would be the signature of A(B).C with: > > module B = struct end > module A(X : sig end) = struct > type t > module C = struct type q = t end > end > > ? Are you perhaps thinking of SML-style generative functors here? Because with Ocaml's applicative functors F(A) in fact always returns the same abstract types, and you _can_ actually refer to types via the notation F(A).t ;-) /Andreas ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Caml-list] Re: "module type of" on sub-module of functor result 2012-02-22 18:49 ` Andreas Rossberg @ 2012-02-22 23:17 ` Jacques Garrigue 2012-02-23 10:05 ` Gabriel Scherer 0 siblings, 1 reply; 12+ messages in thread From: Jacques Garrigue @ 2012-02-22 23:17 UTC (permalink / raw) To: Andreas Rossberg; +Cc: Gabriel Scherer, caml List On 2012/02/23, at 3:49, Andreas Rossberg wrote: > On Feb 22, 2012, at 18.24 h, Gabriel Scherer wrote: >>> [A(B)] and [A.B] are syntacticly valid module_expr's but >>> [A(B).C] isn't. Is this because of an inherent limitation in the >>> module system? >> >> I believe so. When you apply a functor, you may get fresh types as a >> result -- the generative (abstract, algebraic) types of the functor >> image. If you write `module M = A(B)`, the fresh types have a clear >> identity: M.t, M.q etc; similarly if you pass A(B) to a functor with >> formal parameter X, it is X.t, X.q etc. But if you write `module M = >> A(B).C`, there is no syntactic way to name the fresh types generated >> by the functor application; in particular, naming them A(B).t would be >> incorrect -- because you could mix types of different applications. >> >> For example, what would be the signature of A(B).C with: >> >> module B = struct end >> module A(X : sig end) = struct >> type t >> module C = struct type q = t end >> end >> >> ? > > Are you perhaps thinking of SML-style generative functors here? Because with Ocaml's applicative functors F(A) in fact always returns the same abstract types, and you _can_ actually refer to types via the notation F(A).t ;-) This is not strictly correct, because of the possibility of avoidance. I.e. you are allowed to apply a functor to a structure rather than a path, and in that case the behavior of the functor becomes generative, so the problem described by Gabriel really applies in that case. Going back to the question of "module type of", it is currently implemented by typing the module expression in the usual way. So extending it to a stronger form of module expression would require changing that, and introduce extra complexity. Doable, but don't hold your breath... Jacques Garrigue ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Caml-list] Re: "module type of" on sub-module of functor result 2012-02-22 23:17 ` Jacques Garrigue @ 2012-02-23 10:05 ` Gabriel Scherer 2012-02-23 14:30 ` Ashish Agarwal 0 siblings, 1 reply; 12+ messages in thread From: Gabriel Scherer @ 2012-02-23 10:05 UTC (permalink / raw) To: Ashish Agarwal; +Cc: Andreas Rossberg, caml List Apologies for muddling the water here: I'm not a module system expert (but working on it;) and my description was not technically accurate. Thanks Andreas and Jacques for the correction. In the meantime, here is a nicer workaround for you Ashish: (* instead of representing the signature of MapLabels below directly, we build a functor that returns the image signature *) module MAPLABELS (Ord : BatInterfaces.OrderedType) = struct module M = BatMap.Make(Ord) module type S = module type of M.Labels end module MapLabels = struct module Make (Ord : BatInterfaces.OrderedType) : MAPLABELS(Ord).S = struct module M = BatMap.Make(Ord) include M.Labels end end module Test = MapLabels.Make(String) module MS = BatMap.Make(String) (* Test.t and MS.t are compatible, thanks to applicative functors *) let test = Test.add ~key:"foo" ~data:1 MS.empty On Thu, Feb 23, 2012 at 12:17 AM, Jacques Garrigue <garrigue@math.nagoya-u.ac.jp> wrote: > On 2012/02/23, at 3:49, Andreas Rossberg wrote: > >> On Feb 22, 2012, at 18.24 h, Gabriel Scherer wrote: >>>> [A(B)] and [A.B] are syntacticly valid module_expr's but >>>> [A(B).C] isn't. Is this because of an inherent limitation in the >>>> module system? >>> >>> I believe so. When you apply a functor, you may get fresh types as a >>> result -- the generative (abstract, algebraic) types of the functor >>> image. If you write `module M = A(B)`, the fresh types have a clear >>> identity: M.t, M.q etc; similarly if you pass A(B) to a functor with >>> formal parameter X, it is X.t, X.q etc. But if you write `module M = >>> A(B).C`, there is no syntactic way to name the fresh types generated >>> by the functor application; in particular, naming them A(B).t would be >>> incorrect -- because you could mix types of different applications. >>> >>> For example, what would be the signature of A(B).C with: >>> >>> module B = struct end >>> module A(X : sig end) = struct >>> type t >>> module C = struct type q = t end >>> end >>> >>> ? >> >> Are you perhaps thinking of SML-style generative functors here? Because with Ocaml's applicative functors F(A) in fact always returns the same abstract types, and you _can_ actually refer to types via the notation F(A).t ;-) > > This is not strictly correct, because of the possibility of avoidance. > I.e. you are allowed to apply a functor to a structure rather than a path, and in that case the behavior of the functor becomes generative, > so the problem described by Gabriel really applies in that case. > > Going back to the question of "module type of", it is currently implemented by typing the module expression in the usual way. > So extending it to a stronger form of module expression would require changing that, and introduce extra complexity. > Doable, but don't hold your breath... > > Jacques Garrigue > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Caml-list] Re: "module type of" on sub-module of functor result 2012-02-23 10:05 ` Gabriel Scherer @ 2012-02-23 14:30 ` Ashish Agarwal 0 siblings, 0 replies; 12+ messages in thread From: Ashish Agarwal @ 2012-02-23 14:30 UTC (permalink / raw) To: Gabriel Scherer; +Cc: Andreas Rossberg, caml List [-- Attachment #1: Type: text/plain, Size: 3111 bytes --] Thanks for all the helpful replies. On Thu, Feb 23, 2012 at 10:05 AM, Gabriel Scherer <gabriel.scherer@gmail.com > wrote: > Apologies for muddling the water here: I'm not a module system expert > (but working on it;) and my description was not technically accurate. > Thanks Andreas and Jacques for the correction. > > In the meantime, here is a nicer workaround for you Ashish: > > (* instead of representing the signature of MapLabels below directly, > we build a functor that returns the image signature *) > module MAPLABELS (Ord : BatInterfaces.OrderedType) = struct > module M = BatMap.Make(Ord) > module type S = module type of M.Labels > end > > module MapLabels = struct > module Make (Ord : BatInterfaces.OrderedType) : MAPLABELS(Ord).S = > struct > module M = BatMap.Make(Ord) > include M.Labels > end > end > > module Test = MapLabels.Make(String) > module MS = BatMap.Make(String) > (* Test.t and MS.t are compatible, thanks to applicative functors *) > let test = Test.add ~key:"foo" ~data:1 MS.empty > > On Thu, Feb 23, 2012 at 12:17 AM, Jacques Garrigue > <garrigue@math.nagoya-u.ac.jp> wrote: > > On 2012/02/23, at 3:49, Andreas Rossberg wrote: > > > >> On Feb 22, 2012, at 18.24 h, Gabriel Scherer wrote: > >>>> [A(B)] and [A.B] are syntacticly valid module_expr's but > >>>> [A(B).C] isn't. Is this because of an inherent limitation in the > >>>> module system? > >>> > >>> I believe so. When you apply a functor, you may get fresh types as a > >>> result -- the generative (abstract, algebraic) types of the functor > >>> image. If you write `module M = A(B)`, the fresh types have a clear > >>> identity: M.t, M.q etc; similarly if you pass A(B) to a functor with > >>> formal parameter X, it is X.t, X.q etc. But if you write `module M = > >>> A(B).C`, there is no syntactic way to name the fresh types generated > >>> by the functor application; in particular, naming them A(B).t would be > >>> incorrect -- because you could mix types of different applications. > >>> > >>> For example, what would be the signature of A(B).C with: > >>> > >>> module B = struct end > >>> module A(X : sig end) = struct > >>> type t > >>> module C = struct type q = t end > >>> end > >>> > >>> ? > >> > >> Are you perhaps thinking of SML-style generative functors here? Because > with Ocaml's applicative functors F(A) in fact always returns the same > abstract types, and you _can_ actually refer to types via the notation > F(A).t ;-) > > > > This is not strictly correct, because of the possibility of avoidance. > > I.e. you are allowed to apply a functor to a structure rather than a > path, and in that case the behavior of the functor becomes generative, > > so the problem described by Gabriel really applies in that case. > > > > Going back to the question of "module type of", it is currently > implemented by typing the module expression in the usual way. > > So extending it to a stronger form of module expression would require > changing that, and introduce extra complexity. > > Doable, but don't hold your breath... > > > > Jacques Garrigue > > > [-- Attachment #2: Type: text/html, Size: 3962 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Caml-list] Re: "module type of" on sub-module of functor result 2012-02-22 16:40 ` Till Varoquaux 2012-02-22 17:24 ` Gabriel Scherer @ 2012-02-22 17:35 ` Ashish Agarwal 2012-02-22 17:48 ` Gabriel Scherer 1 sibling, 1 reply; 12+ messages in thread From: Ashish Agarwal @ 2012-02-22 17:35 UTC (permalink / raw) To: Till Varoquaux; +Cc: Milan Stanojević, Hezekiah M. Carty, Caml List [-- Attachment #1: Type: text/plain, Size: 2311 bytes --] Here's an example I still don't know how to accomplish: module Map = struct module Make (Ord : BatInterfaces.OrderedType) : sig include module type of BatMap.Make(Ord).Labels (* this line is invalid *) end = struct include BatMap.Make(Ord) include Labels end end The idea is I only want "module type of Labels" for the functor's output, but I need BatMap.Make(Ord) within the implementation (perhaps to implement some other functions). I thought I can simply replace the line "include BatMap.Make(Ord)" with "open BatMap.Make(Ord)", and then not provide the explicit signature. But "open BatMap.Make(Ord)" gives a syntax error. 2012/2/22 Till Varoquaux <till@pps.jussieu.fr> > 2012/2/22 Milan Stanojević <milanst@gmail.com>d > > On Tue, Feb 21, 2012 at 3:32 PM, Hezekiah M. Carty <hez@0ok.org> wrote: > >> On Tue, Feb 21, 2012 at 2:37 PM, Ashish Agarwal <agarwal1975@gmail.com> > wrote: > >>> I must've accidentally deleted part of my email before hitting send. > The > >>> point was to make the first code sample compile after removing the > commented > >>> line. But that is not allowed; I get a syntax error: > >>> > >>> $ ocamlfind ocamlc -c -package batteries a.ml > >>> File "a.ml", line 6, characters 38-39: > >>> Error: Syntax error: 'end' expected > >>> File "a.ml", line 4, characters 16-19: > >>> Error: This 'sig' might be unmatched > >>> > >>> I'm wondering if there is a better solution than my second code sample. > >>> > > > > I would consider this a bug. I think than any module expression than > > can be used with "include" should be usable with "include module type > > of" > > > > -- > > Caml-list mailing list. Subscription management and archives: > > https://sympa-roc.inria.fr/wws/info/caml-list > > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > > Bug reports: http://caml.inria.fr/bin/caml-bugs > > > > Milan is right: the language grammar does say that both [include] and > [module type of] should work on module_expr. However, based upon the > manual(*), [A(B)] and [A.B] are syntacticly valid module_expr's but > [A(B).C] isn't. Is this because of an inherent limitation in the > module system? > > [*]http://caml.inria.fr/pub/docs/manual-ocaml/manual019.html#module-expr > [-- Attachment #2: Type: text/html, Size: 3711 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Caml-list] Re: "module type of" on sub-module of functor result 2012-02-22 17:35 ` Ashish Agarwal @ 2012-02-22 17:48 ` Gabriel Scherer 0 siblings, 0 replies; 12+ messages in thread From: Gabriel Scherer @ 2012-02-22 17:48 UTC (permalink / raw) To: Ashish Agarwal Cc: Till Varoquaux, Milan Stanojević, Hezekiah M. Carty, Caml List You could use the following work-around, which introduces an additional layer to have some space to name the functor application: module Map = struct module Make (Ord : BatInterfaces.OrderedType) = struct module M = BatMap.Make(Ord) module Result : module type of M.Labels = struct include M.Labels end end end I suppose that may not suit your need -- you probably want to mimic an existing hierarchy without changing it -- but it's difficult to do better with such a reduced example, where you don't even need the signature anyway. 2012/2/22 Ashish Agarwal <agarwal1975@gmail.com>: > Here's an example I still don't know how to accomplish: > > module Map = struct > module Make (Ord : BatInterfaces.OrderedType) : sig > include module type of BatMap.Make(Ord).Labels (* this line is invalid > *) > end = struct > include BatMap.Make(Ord) > include Labels > end > end > > The idea is I only want "module type of Labels" for the functor's output, > but I need BatMap.Make(Ord) within the implementation (perhaps to implement > some other functions). > > I thought I can simply replace the line "include BatMap.Make(Ord)" with > "open BatMap.Make(Ord)", and then not provide the explicit signature. But > "open BatMap.Make(Ord)" gives a syntax error. > > > 2012/2/22 Till Varoquaux <till@pps.jussieu.fr> >> >> 2012/2/22 Milan Stanojević <milanst@gmail.com>d >> > On Tue, Feb 21, 2012 at 3:32 PM, Hezekiah M. Carty <hez@0ok.org> wrote: >> >> On Tue, Feb 21, 2012 at 2:37 PM, Ashish Agarwal <agarwal1975@gmail.com> >> >> wrote: >> >>> I must've accidentally deleted part of my email before hitting send. >> >>> The >> >>> point was to make the first code sample compile after removing the >> >>> commented >> >>> line. But that is not allowed; I get a syntax error: >> >>> >> >>> $ ocamlfind ocamlc -c -package batteries a.ml >> >>> File "a.ml", line 6, characters 38-39: >> >>> Error: Syntax error: 'end' expected >> >>> File "a.ml", line 4, characters 16-19: >> >>> Error: This 'sig' might be unmatched >> >>> >> >>> I'm wondering if there is a better solution than my second code >> >>> sample. >> >>> >> > >> > I would consider this a bug. I think than any module expression than >> > can be used with "include" should be usable with "include module type >> > of" >> > >> > -- >> > Caml-list mailing list. Subscription management and archives: >> > https://sympa-roc.inria.fr/wws/info/caml-list >> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> > Bug reports: http://caml.inria.fr/bin/caml-bugs >> > >> >> Milan is right: the language grammar does say that both [include] and >> [module type of] should work on module_expr. However, based upon the >> manual(*), [A(B)] and [A.B] are syntacticly valid module_expr's but >> [A(B).C] isn't. Is this because of an inherent limitation in the >> module system? >> >> [*]http://caml.inria.fr/pub/docs/manual-ocaml/manual019.html#module-expr > > ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2012-02-23 14:30 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-02-21 18:16 [Caml-list] "module type of" on sub-module of functor result Ashish Agarwal 2012-02-21 19:37 ` [Caml-list] " Ashish Agarwal 2012-02-21 20:32 ` Hezekiah M. Carty 2012-02-22 16:18 ` Milan Stanojević 2012-02-22 16:40 ` Till Varoquaux 2012-02-22 17:24 ` Gabriel Scherer 2012-02-22 18:49 ` Andreas Rossberg 2012-02-22 23:17 ` Jacques Garrigue 2012-02-23 10:05 ` Gabriel Scherer 2012-02-23 14:30 ` Ashish Agarwal 2012-02-22 17:35 ` Ashish Agarwal 2012-02-22 17:48 ` Gabriel Scherer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox