Another question about modules

Another question about modules

[Andre Nathan]

Hello

I'm having an issue that is similar to the one reproduced in the code
below:

a.ml:

module SubA :
  sig
    type t
    val f : t -> unit
    val id : t -> int
  end =
  struct
    type t = { id: int }
    let f = B.f
    let id x = x.id
  end

a.mli:

module SubA :
  sig
    type t
    val f : t -> unit
    val id : t -> int
  end

b.ml:

open A
let f x = print_int (SubA.id x)

b.mli:

open A
val f : SubA.t -> unit


When I compile this, I get the following message:

File "a.ml", line 7, characters 2-75:
Signature mismatch:
Modules do not match:
  sig type t = { id : int; } val f : A.SubA.t -> unit val id : t -> int
end
is not included in
  sig type t val f : t -> unit val id : t -> int end
Values do not match:
  val f : A.SubA.t -> unit
is not included in
  val f : t -> unit


Shouldn't "t" (from A.SubA) and A.SubA.t be recognized as the same type
here? I don't understand why they aren't. Is there any workaround for
this issue or is this kind of thing (yet again) a sign that there's
something fishy in my design?

Thanks in advance,
Andre

Re: [Caml-list] Another question about modules

[Andre Nathan]

I think this is similar to this simpler problem:

a.ml:

  type t = { id: int }
  let f x = print_int x.id; B.f x

a.mli:

  type t
  val f : t -> unit

b.ml:

  let f x = print_int 42

b.mli:

  val f : A.t -> unit


Which results in "This expression has type t but is here used with type
A.t" in a.ml, even though t and A.t are the same type. Is there a
general solution for this kind of situation?

Thanks,
Andre

Re: [Caml-list] Another question about modules

[Ashish Agarwal]

[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

Firstly, you have a circular dependency. How are you compiling? That should
be the first error you get.

On Tue, Jul 15, 2008 at 6:51 PM, Andre Nathan <andre@digirati.com.br> wrote:

> I think this is similar to this simpler problem:
>
> a.ml:
>
>  type t = { id: int }
>  let f x = print_int x.id; B.f x
>
> a.mli:
>
>  type t
>  val f : t -> unit
>
> b.ml:
>
>  let f x = print_int 42
>
> b.mli:
>
>  val f : A.t -> unit
>
>
> Which results in "This expression has type t but is here used with type
> A.t" in a.ml, even though t and A.t are the same type. Is there a
> general solution for this kind of situation?
>
> Thanks,
> Andre
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 1845 bytes --]

Re: [Caml-list] Another question about modules

[Andre Nathan]

Hi

I've run this:

ocamlc -c a.mli
ocamlc -c b.mli
ocamlopt -c a.ml

The third command gives the error. I thought that the circular
dependency problem was related only to mutually-dependent types on
separate modules, but I guess I was wrong.

Searching the archives, it seems that the solution is to eliminate the
references to B in A by passing a function argument to A.f, as in

  type t = { id: int }
  let f bfun x = print_int x.id; bfun x

and then in b.ml something like

  let f x = print_endline (string_of_int 42)
  let _ = let a = { A.id = 1 } in A.f f a

That appears to solve the issue, although in my actual code it means
adding an extra parameter to many functions, since the call to what was
B.f here is somewhat deep in the call stack, so maybe there is a better
solution.

Thanks,
Andre

On Tue, 2008-07-15 at 20:18 -0400, Ashish Agarwal wrote:
> Firstly, you have a circular dependency. How are you compiling? That
> should be the first error you get.
> 
> 
> On Tue, Jul 15, 2008 at 6:51 PM, Andre Nathan <andre@digirati.com.br>
> wrote:
>         I think this is similar to this simpler problem:
>         
>         a.ml:
>         
>          type t = { id: int }
>          let f x = print_int x.id; B.f x
>         
>         a.mli:
>         
>          type t
>          val f : t -> unit
>         
>         
>         b.ml:
>         
>          let f x = print_int 42
>         
>         b.mli:
>         
>          val f : A.t -> unit
>         
>         
>         Which results in "This expression has type t but is here used
>         with type
>         A.t" in a.ml, even though t and A.t are the same type. Is
>         there a
>         general solution for this kind of situation?
>         
>         Thanks,
>         
>         Andre
>         
>         _______________________________________________
>         Caml-list mailing list. Subscription management:
>         http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
>         Archives: http://caml.inria.fr
>         Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>         Bug reports: http://caml.inria.fr/bin/caml-bugs
>         
> 
> 

Re: [Caml-list] Another question about modules

[Ashish Agarwal]

[-- Attachment #1: Type: text/plain, Size: 2592 bytes --]

It seems the circular dependency error is given only when you do

ocamlbuild a.native

If you build byte code or use ocamlc directly as you did, then you get the
type mismatch error. Not sure why. In any case, you should consider
restructuring your code to eliminate the circularity. This is usually
possible and leads to cleaner designs.


On Tue, Jul 15, 2008 at 8:44 PM, Andre Nathan <andre@digirati.com.br> wrote:

> Hi
>
> I've run this:
>
> ocamlc -c a.mli
> ocamlc -c b.mli
> ocamlopt -c a.ml
>
> The third command gives the error. I thought that the circular
> dependency problem was related only to mutually-dependent types on
> separate modules, but I guess I was wrong.
>
> Searching the archives, it seems that the solution is to eliminate the
> references to B in A by passing a function argument to A.f, as in
>
>  type t = { id: int }
>  let f bfun x = print_int x.id; bfun x
>
> and then in b.ml something like
>
>  let f x = print_endline (string_of_int 42)
>  let _ = let a = { A.id = 1 } in A.f f a
>
> That appears to solve the issue, although in my actual code it means
> adding an extra parameter to many functions, since the call to what was
> B.f here is somewhat deep in the call stack, so maybe there is a better
> solution.
>
> Thanks,
> Andre
>
> On Tue, 2008-07-15 at 20:18 -0400, Ashish Agarwal wrote:
> > Firstly, you have a circular dependency. How are you compiling? That
> > should be the first error you get.
> >
> >
> > On Tue, Jul 15, 2008 at 6:51 PM, Andre Nathan <andre@digirati.com.br>
> > wrote:
> >         I think this is similar to this simpler problem:
> >
> >         a.ml:
> >
> >          type t = { id: int }
> >          let f x = print_int x.id; B.f x
> >
> >         a.mli:
> >
> >          type t
> >          val f : t -> unit
> >
> >
> >         b.ml:
> >
> >          let f x = print_int 42
> >
> >         b.mli:
> >
> >          val f : A.t -> unit
> >
> >
> >         Which results in "This expression has type t but is here used
> >         with type
> >         A.t" in a.ml, even though t and A.t are the same type. Is
> >         there a
> >         general solution for this kind of situation?
> >
> >         Thanks,
> >
> >         Andre
> >
> >         _______________________________________________
> >         Caml-list mailing list. Subscription management:
> >         http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> >         Archives: http://caml.inria.fr
> >         Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> >         Bug reports: http://caml.inria.fr/bin/caml-bugs
> >
> >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 4475 bytes --]

Re: [Caml-list] Another question about modules

[Martin Jambon]

On Tue, 15 Jul 2008, Andre Nathan wrote:

> Hi
>
> I've run this:
>
> ocamlc -c a.mli
> ocamlc -c b.mli
> ocamlopt -c a.ml
>
> The third command gives the error. I thought that the circular
> dependency problem was related only to mutually-dependent types on
> separate modules, but I guess I was wrong.
>
> Searching the archives, it seems that the solution is to eliminate the
> references to B in A by passing a function argument to A.f, as in
>
>  type t = { id: int }
>  let f bfun x = print_int x.id; bfun x
>
> and then in b.ml something like
>
>  let f x = print_endline (string_of_int 42)
>  let _ = let a = { A.id = 1 } in A.f f a
>
> That appears to solve the issue, although in my actual code it means
> adding an extra parameter to many functions, since the call to what was
> B.f here is somewhat deep in the call stack, so maybe there is a better
> solution.

If you have no other choice, you can do something like that:

--- a.ml ---

let b_fun_ref = ref (fun _ -> assert false)
let b_fun x = !b_fun_ref x

let a_fun x =
   ...
   b_fun
   ...

--- b.ml ---

let b_fun x =
  ...
  A.a_fun
  ...

let () =
   A.b_fun_ref := b_fun



For complex projects, the object system happens to be an excellent way of 
avoiding interdependency problems:

* You define class types early. Not a requirement, but highly recommended.
* You develop independent modules that would work with objects of these
   class types, without worrying about inter-dependencies.
* You just pass objects around, since they carry all the functions needed.
* You can have different implementations of the same class type.
* You can use inheritance.

In my opinion, using OCaml objects makes sense only in large 
projects. It's not theoretically or algorithmically exciting, but makes 
things manageable without magic skills.

I would say that objects are not well-suited to represent nodes 
of low-level data structures, because of performance but 
also because you may want to use pattern matching, circularity and other 
things that tuples, records and variants do better.


I hope you'll find this useful
:-)


Martin


> Thanks,
> Andre
>
> On Tue, 2008-07-15 at 20:18 -0400, Ashish Agarwal wrote:
>> Firstly, you have a circular dependency. How are you compiling? That
>> should be the first error you get.
>>
>>
>> On Tue, Jul 15, 2008 at 6:51 PM, Andre Nathan <andre@digirati.com.br>
>> wrote:
>>         I think this is similar to this simpler problem:
>>
>>         a.ml:
>>
>>          type t = { id: int }
>>          let f x = print_int x.id; B.f x
>>
>>         a.mli:
>>
>>          type t
>>          val f : t -> unit
>>
>>
>>         b.ml:
>>
>>          let f x = print_int 42
>>
>>         b.mli:
>>
>>          val f : A.t -> unit
>>
>>
>>         Which results in "This expression has type t but is here used
>>         with type
>>         A.t" in a.ml, even though t and A.t are the same type. Is
>>         there a
>>         general solution for this kind of situation?
>>
>>         Thanks,
>>
>>         Andre
>>
>>         _______________________________________________
>>         Caml-list mailing list. Subscription management:
>>         http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
>>         Archives: http://caml.inria.fr
>>         Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>>         Bug reports: http://caml.inria.fr/bin/caml-bugs
>>
>>
>>
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

--
http://wink.com/profile/mjambon
http://mjambon.com/

Re: [Caml-list] Another question about modules

[Daniel Bünzli]

Le 16 juil. 08 à 03:05, Ashish Agarwal a écrit :

> It seems the circular dependency error is given only when you do
>
> ocamlbuild a.native

Some errors are reported differently when you use ocamlbuild because  
of its automatic dependency analysis, I started a list here [1].

Daniel

[1] http://brion.inria.fr/gallium/index.php/New_kinds_of_build_errors

Re: [Caml-list] Another question about modules

[Andre Nathan]

On Wed, 2008-07-16 at 03:54 +0200, Martin Jambon wrote:
> I hope you'll find this useful
> :-)

It was, thanks :)

I am translating this code to ocaml, and the original version is written
in an object-oriented fashion, so there's naturally an impedance
mismatch on the translation... I'll wait a bit to decide if I should use
objects in ocaml or if it's better to try to redesign the code to make
it more... ocamly :p

Thanks again,
Andre