From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.9 required=5.0 tests=AWL,DNS_FROM_RFC_POST, HTML_MESSAGE,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id C8599BB84 for ; Wed, 16 Jul 2008 03:05:27 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFAKrlfEjAXQIm/2dsb2JhbACCPjSPCJdYhnQ X-IronPort-AV: E=Sophos;i="4.30,369,1212357600"; d="scan'208";a="15144355" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 16 Jul 2008 03:05:27 +0200 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m6G15QA3012238 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 16 Jul 2008 03:05:27 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQBAFnmfEhA6aaxdGdsb2JhbACCPjSPCEMBDAMEBgcPBZZhhnQ X-IronPort-AV: E=Sophos;i="4.30,369,1212357600"; d="scan'208";a="15144561" Received: from py-out-1112.google.com ([64.233.166.177]) by mail3-smtp-sop.national.inria.fr with ESMTP; 16 Jul 2008 03:05:25 +0200 Received: by py-out-1112.google.com with SMTP id p76so3220978pyb.10 for ; Tue, 15 Jul 2008 18:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=86hGcxHuCGAU60/Wm7oHc9+HMKn63Ecrw4JHHE7B8lA=; b=tKcL+VzlCZC8dUl67roog1PCprayTxxe9pT8pbtL4XG1g5wjcdCutrvEsnHq7lIkMZ IF+r6bElZCCCNdMY/A/yFdxwMyAp6EvK3LlFm+7M+DNFTSEGkHhgbeHODfGlDNyOUdhG cZ+0+UFy1FM+Ki8fyHzDfQ4rYa7IKjDd+UN5g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=uqPaw7vdfdUuml6sL6FpisNF4RENwSsfmBfO9+O50+MZfF8p2X9+QCppzGQbwyz0Fh x+VN7BGt1CVTtsTJclnkfp8TaSFtkJtpuzaq5b4nwufhui6NbmmYntlJ1IhAm6FLixGA /m7AYZt2x75EkhwbnlfJLeYIoleswkTm4lNIA= Received: by 10.141.66.16 with SMTP id t16mr7859524rvk.168.1216170324090; Tue, 15 Jul 2008 18:05:24 -0700 (PDT) Received: by 10.141.19.4 with HTTP; Tue, 15 Jul 2008 18:05:24 -0700 (PDT) Message-ID: Date: Tue, 15 Jul 2008 21:05:24 -0400 From: "Ashish Agarwal" To: "Andre Nathan" Subject: Re: [Caml-list] Another question about modules Cc: caml-list@inria.fr In-Reply-To: <1216169075.5294.32.camel@homesick> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12029_5901660.1216170324094" References: <1216154495.5294.9.camel@homesick> <1216162299.5294.22.camel@homesick> <1216169075.5294.32.camel@homesick> X-Miltered: at discorde with ID 487D4956.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; byte:01 ocamlc:01 mismatch:01 ocamlc:01 mli:01 mli:01 ocamlopt:01 endline:01 val:01 val:01 beginner's:01 ocaml:01 bug:01 byte:01 mismatch:01 ------=_Part_12029_5901660.1216170324094 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 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 > > 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 > > > > > > > > ------=_Part_12029_5901660.1216170324094 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
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
>
>
>


------=_Part_12029_5901660.1216170324094--