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 VAA07794; Sat, 15 Mar 2003 21:16:55 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA08477 for ; Sat, 15 Mar 2003 21:16:53 +0100 (MET) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from opus.davidb.org (66-27-72-19.san.rr.com [66.27.72.19]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h2FKGqX16559 for ; Sat, 15 Mar 2003 21:16:52 +0100 (MET) Received: from davidb by opus.davidb.org with local (Exim 3.31 #1 (Debian)) id 18uI5K-00010M-00 for ; Sat, 15 Mar 2003 12:16:50 -0800 Date: Sat, 15 Mar 2003 12:16:50 -0800 From: David Brown To: caml-list@pauillac.inria.fr Subject: Re: [Caml-list] Re: Haskell-like syntax Message-ID: <20030315201650.GA3802@opus.davidb.org> References: <005d01c2e76f$92d0f8b0$2713f9ca@WARP> <20030314003336.D748@max.home> <20030315013056.C5826@max.home> <200303141301.59458.seth@cql.com> <20030315082727.E5826@max.home> <20030315105846.GA28233@fichte.ai.univie.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030315105846.GA28233@fichte.ai.univie.ac.at> User-Agent: Mutt/1.4i X-Spam: no; 0.00; caml-list:01 haskell-like:01 mli-files:01 initialized:01 ocaml's:01 elaborated:01 statically:01 dependencies:01 topological:01 mli:01 figuring:01 filenames:01 compiler:01 ocaml:01 simpler:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sat, Mar 15, 2003 at 11:58:46AM +0100, Markus Mottl wrote: > Things are not this easy: the order is actually required for linking, > not for compiling (as long as you provide explicit signatures in > .mli-files). The order during linking determines in which order side > effects will be caused when values are initialized, which only the user > can know. Furthermore, the "mutually recursive modules"-problem is more > of a typing problem than one of compilation. Ada has an interesting approach to this problem. The Ada module system is very similar to ocaml's. However, they don't normally specify what order things happen in (they call it elaboration order). There are a few directives you can put in source files to declare that something else must be elaborated before the current module (package). The GNU Ada compiler has a default mode that is much simpler, and much more like how ocaml does it. The elaboration order is determined by statically analyzing the dependencies, performing a topological sort. It doesn't work if there are circular dependencies, and you have to be more explicit about elaboration. They handle the circular dependencies by allowing the spec (the .mli file) to come before the body (.ml) in the order. This means that the types, and names of functions are available early, but you can't call them until that part has been loaded. The other thing that Ada95 does well is their notion of child packages. The child packages are compiled and elaborated independently of the parents (well, after the parents). For example, I have the modules A, A.B, C and D. C uses A, and D uses A.B, but A.B uses C. The following order would work. A C A.B D You could kind of think of compiling/linking module A.B just adds a new child package to A. After this, D is permitted to use A.B as well. There is a conflict if A already has a definition for B. I've thought about trying to throw this into ocaml. The tricky part is figuring out which .cmi files to look into for the information. Perhaps when you have a reference to A.B.xxx, you would first search for a.b.cmi, and if not, look in a.cmi for the symbol. (Gnu ADA also changes all of the leading dots in the filenames to hyphens for systems that don't like multiple dots in a name, so the name would be a-b.cmi). Ada definitely has some annoying features, but there are some aspects of the language that are well thought out (such as the module system). Dave Brown ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners