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 JAA25775; Thu, 27 Mar 2003 09:10:51 +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 JAA26089 for ; Thu, 27 Mar 2003 09:10:49 +0100 (MET) Received: from athlon.baretta.com ([213.255.109.130]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h2QL2YX28372 for ; Wed, 26 Mar 2003 22:02:34 +0100 (MET) Received: from baretta.com (localhost.localdomain [127.0.0.1]) by athlon.baretta.com (Postfix) with ESMTP id 74C4F273BB; Wed, 26 Mar 2003 22:08:00 +0100 (CET) Message-ID: <3E8216B0.2070206@baretta.com> Date: Wed, 26 Mar 2003 22:08:00 +0100 From: Alessandro Baretta Organization: Baretta srl -- www.baretta.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: it, en MIME-Version: 1.0 To: Chris Hecker , Ocaml Subject: Re: [Caml-list] camlimages vs. labltk 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> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam: no; 0.00; alessandro:01 baretta:01 caml-list:01 camlimages:01 labltk:01 hecker:01 sven:01 namespaces:01 equivalently:01 -pack:01 clashes:01 hashtbl:01 ocamlc:01 generic:01 sematics:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Chris Hecker wrote: > > I think this thread is a misunderstanding masquerading as an argument. > > Alex, I think people (well, I do at least :) want to hear what the > differences between a namespace and the module system are. It seems on > the face of it that fixing pack's implementation would solve the > namespace problem (this was Sven's thought as well), but you don't think > so (or think it's the wrong way to fix it), and I'd like to understand > why, since you've obviously thought about it a bunch. I have been discussing this privately with Sven. I didn't mean to start another thread on the subject, because I knew that inevitably it would lead to big waste of time. As I have mentioned already, I do not think namespaces are a paramount feature in any language. Sven correctly pointed out that C is a pretty successful language and it does not have namespaces. Of course, this is no excuse. Namespaces address the issue of resolving, or mapping if you prefer, identifiers--actually, module names--to module objects--that is to pieces of code, bytecode or native equivalently. In such languages as C or Ocaml, where there are no namespaces, this mapping is simply function from strings to pieces of code. I argue that this mapping gets a little clumsy--and this is common experience--when you have a lot of modules, that is, when you have a lot of distinct pieces of code which you want to identify indipently of each other. 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. let f' x = ... let f = let t = Hashtbl.create 1024 in fun x -> try Hashtbl.find t x with Not_found -> let y = f' x in Hashtbl.add x y; y C has a powerful stripping feature because all computations start from main(), so by apply a graph traversal algorithm you can figure exactly what functions are called and what are not. But in our case computations can arise anywhere. This is why ocamlc links all modules that are passed to it, regardless of whether they are actually referenced anywhere else. Do you see what the problems are with the module system? The module system is great for decomposing a problem into reusable units, but the units become much less versatile if they are packed together. Namespace are much more "lightweight" feature. They address a specific problem: name clashes. They having nothing to do with problem factorization or generic programming. Names exist at a syntactic level, so the solution to a problem pertaining to identifier names must exist at a syntactic level. Modules relate to sematics. Namespaces relate to syntax. Hence, they are orthogonal concepts. It's that simple. Basically, the namespace feature expands the resolution scheme from names to module objects by adding one formal parameter to this mapping. If you'll allow me to use an pseudo-Caml syntax, I could say that we have a function resolution : ~name:string -> module_object We could (should?) have a mapping resolution : ~space:string -> ~name:string -> module_object I hope the pseudo-code I used helped make my point clearer rather than more obscure. Alex ------------------- 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