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 SAA15435; Thu, 27 Mar 2003 18:23:25 +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 SAA14854 for ; Thu, 27 Mar 2003 18:23:23 +0100 (MET) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from opus.davidb.org (66-75-152-1.san.rr.com [66.75.152.1]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h2RHNMX08131 for ; Thu, 27 Mar 2003 18:23:22 +0100 (MET) Received: from davidb by opus.davidb.org with local (Exim 3.31 #1 (Debian)) id 18yb5l-0002sH-00; Thu, 27 Mar 2003 09:23:05 -0800 Date: Thu, 27 Mar 2003 09:23:05 -0800 From: David Brown To: Alessandro Baretta Cc: Chris Hecker , Ocaml Subject: Re: [Caml-list] camlimages vs. labltk Message-ID: <20030327172305.GA10977@opus.davidb.org> References: <3E818E08.2000505@baretta.com> <3E81640C.40009@baretta.com> <20030326083345.GA2985@iliana> <3E816C13.7040507@baretta.com> <20030326105006.GA3891@iliana> <3E818E08.2000505@baretta.com> <4.3.2.7.2.20030326110515.035919b0@localhost> <3E8216B0.2070206@baretta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E8216B0.2070206@baretta.com> User-Agent: Mutt/1.4i X-Spam: no; 0.00; caml-list:01 camlimages:01 labltk:01 alessandro:01 baretta:01 -pack:01 clashes:01 namespaces:01 encapsulate:01 mylib:01 submodules:01 helper:01 mli:01 foo:01 haskell:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wed, Mar 26, 2003 at 10:08:00PM +0100, Alessandro Baretta wrote: > Module encapsulation ? la -pack addresses a different issue. > Packing eliminates the name clashes by reducing the number > of distinct modules. A lot of small modules are packed into > one big one, and, voil?, the name clashes are gone. Yes, but > this is a side effect. The main effect is that you get one > big chunk of code which can no longer be refactored into its > individual components: problems arise whenever one of the > packed modules defines values which, upon definition, > immediately perform computations. Even functional values > could be defined in such a way as to engender a computation. I think talking about namespaces is addressing the wrong problem. Namespaces are merely a subset of the functionality already in the module system. They are usually put into languages that don't have good module systems. The -pack option is an attempt (in my impression a poor one) to solve a different problem, easier separate compilation. The functionality of -pack could also be done (more difficulty) by choosing weird names within the parent module, and having a single module encapsulate everything. I've seen code that does it this way. If I get some spare time, I may try implementing the suggestion I gave before, which I think is a nice elegant solution that doesn't change the syntax or grammar of the language at all. Here it is, boiled down: Say for example, I want a large system Mylib, in it I want three submodules: Mylib.Types, Mylib.Helper, Mylib.Process. My proposal is to have the following files: mylib.ml, mylib.mli - might be empty if nothing is declared at the top. mylib-types.mli mylib-types.ml mylib-helper.mli mylib-helper.ml mylib-process.mli mylib-process.ml When compiling other code, a reference to Mylib.Helper.foo will first check for a mylib-helper.cmi, and then in mylib.cmi (in case the module is defined there). GHC (Haskell) does something similar to this. To do it, some though will have to be put into the exact semantics, this is just the general idea. 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