From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id BAA20774; Mon, 19 Mar 2001 01:01:28 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id BAA20943 for ; Mon, 19 Mar 2001 01:01:27 +0100 (MET) Received: from shell5.ba.best.com (shell5.ba.best.com [206.184.139.136]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f2J01Q121231 for ; Mon, 19 Mar 2001 01:01:26 +0100 (MET) Received: from localhost (bpr@localhost) by shell5.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id QAA15641 for ; Sun, 18 Mar 2001 16:01:25 -0800 (PST) Date: Sun, 18 Mar 2001 16:01:25 -0800 (PST) From: Brian Rogoff To: caml-list@inria.fr Subject: Re: [Caml-list] recursive modules redux, & interface files In-Reply-To: <4.3.2.7.2.20010318142842.00d85300@shell16.ba.best.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sun, 18 Mar 2001, Chris Hecker wrote: > Two questions/problems: Just one answer/solution I'm afraid, but I also give a grotesque workaround... > 2. Also, on a related note, why do the interface file and the > implementation file (or equivalently, I believe, the signature and > structure) both have to have all the concrete types duplicated? I can > see the value of having interfaces that hide some implementation stuff > and abstract types, but if I've got a big fully-specified variant type > in a .mli file, it's annoying and error prone (yes, I know the compiler > will catch it) to have to retype the whole thing into the ml file > (which I have to do if I want to hide anything else in the ml file, meaning I > can't just have an ml without an mli). Is this something the > "include" keyword takes care of? No, but if you are finding this really onerous then you can use "open" by creating a "pure" mli file with your gignatic variant type and opening it in the mli and ml file where it is needed. Does that help? -- Brian PS : There are some ways to get around the fact that the linker requires ordering, either by putting the mutually recursive functions in the same module (I assume you know this) or by breaking the cycle with an indirection (first rule of programming: any problem can be solved with another level of indirection :-). In this case, the indirection can be provided by passing in functions to foo and bar. Yeah, it's ugly and all that but it is a workaround. (* t1.mli *) val foo : (int -> int) -> int -> int (* t2.mli *) val bar: (int -> int) -> int -> int (* t1.ml *) let foo f x = if x = 1 then f x else x (* t2.ml *) let bar f x = if x = 2 then f (x-1) else x (* main.ml *) let rec foo_aux x = T2.bar bar_aux x and bar_aux x = T1.foo foo_aux x let _ = print_int (T2.bar bar_aux 2) ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr