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 LAA28451; Sun, 20 Jul 2003 11:56:01 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA27240 for ; Sun, 20 Jul 2003 11:55:59 +0200 (MET DST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.189]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h6K9txf17066 for ; Sun, 20 Jul 2003 11:55:59 +0200 (MET DST) Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 19eAv6-0000Xf-00; Sun, 20 Jul 2003 11:55:56 +0200 Received: from [80.129.108.84] (helo=gate.gerd-stolpmann.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 19eAv5-0003FC-00; Sun, 20 Jul 2003 11:55:55 +0200 Received: from ice.gerd-stolpmann.de (ice.gerd-stolpmann.de [192.168.0.13]) by gate.gerd-stolpmann.de (Postfix) with ESMTP id 5668356EF; Sun, 20 Jul 2003 11:55:52 +0200 (CEST) Received: by ice.gerd-stolpmann.de (Postfix, from userid 1000) id 2227DB014; Sun, 20 Jul 2003 11:55:49 +0200 (CEST) Subject: RE: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?)) From: Gerd Stolpmann To: BdB Cc: Fernando Alegre , Shawn Wagner , caml-list@inria.fr In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1058694948.6556.141.camel@ice.gerd-stolpmann.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 20 Jul 2003 11:55:49 +0200 X-Loop: caml-list@inria.fr X-Spam: no; 0.00; gerd:01 stolpmann:01 caml-list:01 cpan:01 on-topic:01 reuse:01 packagers:01 renaming:01 findlib:01 barrier:01 rank:99 namespaces:01 immune:99 cpan-like:01 disadvantage:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Am Sam, 2003-07-19 um 22.40 schrieb BdB: > 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. Both are related, at least in the sense that problems with code reuse are often detected by packagers, or by users of packages. Furthermore, packagers are the natural "authority" to ask the upstream developers to change their software for better reuse. > 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_*? Given that I restructure my libraries from time to time from the grounds up, this is really one of the things I try to take easy. Other types of changes cause much more problems, especially inconveniences by the users who have to follow the changes. > 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. Yes, sure. But other "processes" do this, too, especially the namespace approach you suggest. > 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 That sounds really complicated! I am more and more thinking that we are on the wrong track. Every hierarchical solution has the disadvantage that it needs administration. I have an alternative, the "relational solution". What we want to manage is nothing but a database of top-level modules, and we want to find a way to uniquely identify every row of the "modules table". Currently, the rows have only two fields: "name", and "contents". My suggestion is to introduce further fields, like "author", "organization", maybe even "version" and so on. So a module can have a set of attributes: module M = sig attributes author = "Gerd Stolpmann", organization = "ocaml-programming.de", version = "42.5" ... further signature ... end You can now disambiguate module names by these attributes, e.g. open M[author="Gerd Stolpmann"] open M[version>="42.0"] To minimize the notation, I would suggest a default selection for the whole module context: select author="Gerd Stolpmann" for M select organization="INRIA" | organization="..." | ... for * The latter would be applied to all unqualified occurrences of top-level module names, so you have typically only one extra line at the top of every module implementation. I would suppose this is very simple to implement in the compilers. There is already meta data for top-level modules (the MD5 checksum), so it is only an extension of this. The best thing is that it is very natural for developers of libraries to add the attributes to their exported modules. Collisions can be fixed incrementally as they occur (even packagers could fix them easily themselves). Maybe there could be a "style guide" explaining the problems and how to address them by proper attributing the modules. What do you think about this? Gerd -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de ------------------------------------------------------------ ------------------- 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