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 LAA05061; Wed, 26 Mar 2003 11:50:12 +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 LAA05964 for ; Wed, 26 Mar 2003 11:50:10 +0100 (MET) Received: from mwinf0502.wanadoo.fr (smtp2.wanadoo.fr [193.252.22.26]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h2QAoAX09018 for ; Wed, 26 Mar 2003 11:50:10 +0100 (MET) Received: from iliana (AStrasbourg-206-1-20-128.abo.wanadoo.fr [81.49.169.128]) by mwinf0502.wanadoo.fr (Postfix) with ESMTP id BFCD3E8002EE; Wed, 26 Mar 2003 11:50:09 +0100 (CET) Received: from luther by iliana with local (Exim 3.36 #1 (Debian)) id 18y8Tv-00012a-00; Wed, 26 Mar 2003 11:50:07 +0100 Date: Wed, 26 Mar 2003 11:50:06 +0100 To: Alessandro Baretta Cc: Sven Luther , Ocaml Subject: Re: [Caml-list] camlimages vs. labltk Message-ID: <20030326105006.GA3891@iliana> References: <3E81640C.40009@baretta.com> <20030326083345.GA2985@iliana> <3E816C13.7040507@baretta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E816C13.7040507@baretta.com> User-Agent: Mutt/1.5.4i From: Sven Luther X-Spam: no; 0.00; sven:01 luther:01 dpt-info:01 u-strasbg:01 caml-list:01 camlimages:01 labltk:01 alessandro:01 baretta:01 -pack:01 wisely:99 namespaces:01 submodules:01 cruft:01 dynamically:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wed, Mar 26, 2003 at 10:00:03AM +0100, Alessandro Baretta wrote: > > > Sven Luther wrote: > >On Wed, Mar 26, 2003 at 09:25:48AM +0100, Alessandro Baretta wrote: > > > > > >There is already the -pack option, and the right thing to solve this > >problem would be to build all libraries to make usage of it (if > >possible). So you would have a CamlImage.Image module and a Labltk.Image > >module, which work pretty well. > > > >Now, library writters just need to modify their build system to take > >advantage of it, starting by the INRIA released libraries, especially > >the ones provided by the ocaml tarball directly like labltk. > > Sven, someone on this list wisely pointed out that you buy > nothing by telling someone else "You don't need that > feature". We do need namespaces. It might not be paramount: And the module system offers it. The problem you have is not about namespace, but because the current namespace solution has a few technical problems that need to be solved. The module system provides a theoretically and well proved way of doing namespace management, and you want to put it aside for a java-inspired quick hack because of technicalities ? > I'm pretty sure there is something more important to be done > at Inria. But, please, don't tell me that -pack will cure > cancer, promote democracy, establish universal peace, and > make my teeth look whiter. Packing does not allow It is the right solution for the current problem. The problem is that you want to solve the namespace issue, and the correct way of doing this is by moving the modules of a library to be submodules of the library module or something such. This can be achieved best with the -pack option right now, even if there are a few problems with it. > factorizing your code--bytecode, actually--in small reusable > units. One big .cmo is not as flexible as a .cma. I simply > might not want to link all of a library: what if it's > modules contain side-effects? Well, if you look at the C libraries, they are either static libraries, where you get ride of the cruft with strip, or dynamically loaded shared libraries. I don't think there is a strip equivalent, for ocaml (be it bytecode or native code, not sure about native code though) but the current inclusion granularity is at the .cmo level. This may be changed in the future though. As for dynamically loaded, shared ocaml code, this is also not yet available, but is also a requested feature, which would make the above stripping unnecessary, i think. So, the problem is not so much that we need a namespace solution, we clearly have one already, but that we need smaller granularity in code inclusion in .cmo or .cmx, or a strip utility or functionality which can be called by ocamlc at link time and/or true dynamically linked and shared libraries. Both of these things have often be requested, but cause some problems, if i understood right what the ocaml team has to say about it. As for side-effects, i didn't really think about that, but i guess that you could easily implement the modules so that the side effect do happen when you call a module initialization function or something such. I don't think it really is good practice to use toplevel global side effect for library code anyway. > So -pack is good, but > namespaces are still a necessary feature to Ocaml as to any > industrial level programming language. No, the namespace feature is already there, altough not much used in reality, the problems are elsewhere. Friendly, Sven Luther ------------------- 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