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 WAA12134; Sat, 19 Jul 2003 22:43:39 +0200 (MET DST) 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 WAA08553 for ; Sat, 19 Jul 2003 22:43:37 +0200 (MET DST) Received: from mwinf0202.wanadoo.fr (smtp7.wanadoo.fr [193.252.22.29]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h6JKhbT22901 for ; Sat, 19 Jul 2003 22:43:37 +0200 (MET DST) Received: from bdb (ASt-Lambert-104-1-6-83.w81-51.abo.wanadoo.fr [81.51.96.83]) by mwinf0202.wanadoo.fr (SMTP Server) with SMTP id 2BAB7A400198; Sat, 19 Jul 2003 22:43:36 +0200 (CEST) From: "BdB" To: "Gerd Stolpmann" , "Fernando Alegre" Cc: "Shawn Wagner" , Subject: RE: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?)) Date: Sat, 19 Jul 2003 22:40:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <1058618316.6556.94.camel@ice.gerd-stolpmann.de> Importance: Normal X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 cpan:01 on-topic:01 reuse:01 -pack:01 in-memory:01 spawns:01 threads:01 camlimages:01 labltk:01 developer's:01 200208:01 findlib:01 renaming:01 gerd:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Packaging and easing the distribution of libraries, is one issue ; naming hierarchy, i.e. ensuring non-collision of names used by different libraries, is another one. Both issues are very on-topic and need to be addressed. The only topic here is how to enable code reuse among the O'CaML community. One question I have about "-pack": say you want to distribute SomeDataFormat.Parsing, SomeDataFormat.PrettyPrinting and that you want to factor in-memory representations of data into SomeDataFormat.Common (this situation almost always occurs for I/O modules). How do you do this with -pack? How do you distribute these 3 modules to developers? Developer 1 wants to only parse so should have Parsing and Common, developer 2 wants to only print so should have PrettyPrinting and Common, and developer 3 wants to do both so should have them all... Wouldn't "-pack" enable you to only distribute one big SomeDataFormat module? If so, then as of now the "-pack" option can't be used to distribute library modules. Another way is to use prefixed top-level names such as SomeDataFormat_Parsing for modules -- like in C, which does not have any form of namespace structure, but whose community respects a code of practice that is to give prefixes to all exported functions. I personally am not too keen on this. One major issue I have with this is that when you decide to release some files that were used internally, you have to add a prefix to your top-level files. Staying at the top-level implies having to run sed through all your code (in the easiest case). I guess the intent of "-pack" was to simplify this... GS> I would say [namespace clash] is a minor problem [...]. This problem is not minor. It has shown up in the past repeatedly up to the point that people can't solve it on their own and send an email to the mailing list, which usually spawns a thread similar to this one. It will all the more occur as the community scales up. Here's a pick of some threads in this mailing list: * << I observed that both camlimages and labltk have a module named "Image". >> @ http://caml.inria.fr/archives/200303/msg00345.html * Someone wrote a module named "array.ml" and realized later they couldn't access the "standard" array module anymore. Someone proposed to rename the standard library modules to Std.* so that they don't clobber the developer's namespace @ http://caml.inria.fr/archives/200208/msg00432.html * Name clash between findlib and dynlink's "Meta" modules @ http://caml.inria.fr/archives/200209/msg00232.html GS> I would say [that name clash is] not even a technical [problem]. True! I am not talking about a specific language feature, but about a problem whose solution may involve a combination of standard community practices, utilities, and language features. Just because it is not entirely technical does not mean it is not important. GS> Why don't you ask the developers to rename their modules? I do not think it is very wise to "ask" too much -- especially such boring stuff as renaming -- in case of voluntary donations. Gerd, you are the author of findlib, which has been found out to collide with dynlink's Meta module, what did you think about having to rename all your modules to fl_*? Because you are an exceptionally generous contributor to the O'CaML community, you were willing to do this. But this raises the developer "entry barrier" significantly. All the requirements I can come up with for now are listed below; I am curious to see what the list thinks about this. The numbers are just to keep track, not a rank. 1. The top-level namespace should always be free to end-application developers 2. There should be syntactic sugar like "open" to access elements of the namespace in a context-sensitive manner -- some core namespaces should also be "open"-ed by default. 3. There should always be the option to use "fully qualified names" whose interpretation is immune to context variations. At any point in the code, all the namespace should be "locally accessible"; i.e. accessible by simply typing stuff where the cursor is, not needing to modify anything elsewhere. 4. It should be relatively painless for an application writer to spin off some top-level files of an application as a community library. This means it should be easy to move modules around in the namespace, or at least to push top-level modules down to other areas in the namespace. 5. The migration path for end-application developers should equally be easy (from the currently-flat namespace) 6. The SomeDataFormat example above must be able to be to be distributed in three parts situated at a hierarchical level below SomeDataFormat. 7. There should be room for - Modules managed by the core language team (like the java.* namespace in Java) - Managed community modules : CPAN-like archives - Un-managed community modules : independent releases of libraries Finally, I came across this old post by Yurii A. Rashkovskii @ http://caml.inria.fr/archives/200211/msg00002.html . I don't know if there have been any follow-ups to it, but it gives an example of namespace added through preprocessing. Worth reading at any rate... BdB. > -----Message d'origine----- > De : owner-caml-list@pauillac.inria.fr > [mailto:owner-caml-list@pauillac.inria.fr]De la part de Gerd Stolpmann > Envoyé : samedi 19 juillet 2003 14:39 > À : Fernando Alegre > Cc : Shawn Wagner; caml-list@inria.fr > Objet : Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?)) > > > Am Sam, 2003-07-19 um 14.18 schrieb Fernando Alegre: > > I use Debian and I am happy, thank you very much, but that's good enough > > for me. I guess RedHat/Suse/Mandrake users think similarly, and windows > > users... get what they pay for, sorry. > > I.e. nothing. Debian is the only distribution with good O'Caml packages > I know. From a common point of view this is a very unsatisfactory > situation, because Debian is not the world. > > > Packaging is off-topic. The on-topic problem is module naming. If I want > > to use two packages in my program, but both have a module called Stuff, > > I have a problem. Current workarounds: > > I would say this is a minor problem, and not even a technical one. Why > don't you ask the developers to rename their modules? > > > 1) Use -pack to wrap all package1 modules under Package1, and > all package2 > > modules under Package2. Problem: -pack uses a cmo instead of > a cma. So, > > many unnecessary modules might be linked into my program. > This affects > > compilation time and size, but it should not affect run time. > > > > 2) Manually rename some modules. Problem: Each time I upgrade, I have to > > do the renaming again. Time-consuming. > > > > The on-topic question is: Is there something better that the > OCaml developers > > could provide without taking them too much effort? User-only > solutions are > > not going to make it. > > Gerd ------------------- 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