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 CAA11946; Tue, 22 Jul 2003 02:05:21 +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 CAA00304 for ; Tue, 22 Jul 2003 02:05:19 +0200 (MET DST) Received: from mwinf0604.wanadoo.fr (smtp3.wanadoo.fr [193.252.22.25]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h6M05Af12689 for ; Tue, 22 Jul 2003 02:05:10 +0200 (MET DST) Received: from bdb (ASt-Lambert-104-1-5-24.w81-49.abo.wanadoo.fr [81.49.43.24]) by mwinf0604.wanadoo.fr (SMTP Server) with SMTP id 39F7228000B6; Tue, 22 Jul 2003 02:05:08 +0200 (CEST) From: "BdB" To: "Christian Lindig" , "Gerd Stolpmann" Cc: "BdB" , "Fernando Alegre" , "Shawn Wagner" , Subject: RE: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?)) Date: Tue, 22 Jul 2003 02:01:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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: <20030720183027.GB559@eecs.harvard.edu> Importance: Normal X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 cpan:01 gerd's:01 orthogonal:01 criticism:01 java's:01 stupid:01 model:01 avoided:01 nameclash:01 shortcomings:01 perl's:01 namespaces:01 isomorphic:01 policies:99 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Hi, Gerd's idea is indeed interesting. I think it subsums my original idea of a namespace. Any basis for disambiguation is to use meta-data. In the Java case, meta-data = package name = mono-dimensional hierarchical space. Gerd's proposal is, the meta-data can be multidimensional. I still think we should have at least the "primary key" of the meta-data to be structured hierarchically. Hierarchy allows delegation, and delegation is *very* good for namespace management. If I can easily claim some portion of the namespace, I will use it and not bother anyone with it. Delegation is the basis of namespace management. If we have a hierarchy in one of the meta-data, we can state a community naming policy like: /Std/* == managed by the language team /Hump/* == managed by some "community of hump gurus" (?) yet to be defined /* == managed by IANA (i.e. Internet TLDs): for contributors who want to enable others to use their code but don't want to deal with hump gurus This is just an example policy, and I insist that we should decouple the mechanism discussion from the policy discussion. What is important is that delegation can be enabled easily. Flattening multi-dimensional meta-data to one dimension involves choosing an arbitary order between keys. I find this very annoying for music. I can never decide between "Beethoven/Sonatas/Piano/Moonshine Sonata", "Piano/Sonatas/Beethoven/Moonshine Sonata", etc. So, you may call me a fan of the general idea to have many metadata dimensions. I'm not sure it happens as often for software modules, though. For Java, there's a kind of implicit ordering between metadata: author is before. The thing is, often times the hierarchy below the author is author-specific and cannot be generalized to other authors. So it makes sense to be last, in my opinion. Unlike music where genre, instrument and author are really orthogonal to each other. Maybe version can be used to allow the same library to be linked twice with two different versions in the same software, but this looks like an odd case. We should check that there are no other ways of solving the "two different library versions linkage" problem... What I think we should not do is succomb to the "NIH syndrom." Let's be honest: I see many criticism of Java's "simple and stupid" package model, but I don't really understand: hasn't the Java community pretty much scaled up and avoided the nameclash problem? I can certainly see shortcomings in the Java approach, but anyone calling that a failure would be simply negating the reality that there are millions of Java developers and that namespace clash is not a problem there -- vs. how many O'CaML developers and already lots of nameclash? Let's not be afraid or shameful to simply copy what's working elsewhere. Note for perl fans out there, I am considering Java and Perl's technical solutions for namespaces to be roughly isomorphic. The naming policies are certainly different, given the CPAN-managed namespace vs. IANA-managed namespace, but I insist (again) on separating the two aspects. I have a concrete proposal: * "Let's KISS first" (keep it simple and stupid). Let's start out by building a mono-dimensional hierarchical namespace model a la Java. This way, we can at least show the INRIA how we, as a community, would like it done. Simply complaining about nameclash to the INRIA cannot be expected to work -- especially considering what we are paying for O'CaML. * Gerd's relational metadata proposal is more powerful, but also undoubtedly more difficult to implement; What I propose is step-by-step: once we have a model for simple and stupid Java-like namespace, Gerd can make a detailed proposition of an extension that introduces multi-dimensional meta-data, and we can see then if it is worth it. In the meantime, we should of course not rule out the possibility that meta-data becomes multi-dimensional. I have observed that the nameclash issue has shown up four to five times in the past on this mailing list. Each time, what happened was that a passionate brainstorming session followed, but no action was taken in the end and nothing resulted but entertaining logs. I am getting tired of seeing the same topic raised over and over again, and I don't think one more thread of "why don't we just" posts is going to solve anything. This is why I suggest that we work through the following steps: 1/ agreeing on our purpose; expressing what is wrong now and how we would like it to change, through a list of high-level requirements; 2/ agreeing on what needs to be done, technically and non-technically, to fulfil these requirements (language mods? compiler mods? preprocessor? naming policy?) 3/ doing it. I have taken part in a couple of software-related community working groups that have used similar processes and have produced useful solutions to the problems they had set to resolve. That's why although such an approach takes time and has overhead compared to regular mailing list participation, I hope that this way we could finally *get rid* of this issue together instead of just brainstorming about it regularly and not getting anything done. Only through a continued effort on this topic can we progress. We could use the mailing list to distribute work among us and sync up every week or two, mark what we have done, agree on what to do next and on who does it. I would like to invite interested people to seriously commit over time to solving the nameclash issue through such an approach. *Not more time* is required than what you currently spend on this mailing list, just the same amount of time but that you will use to think about this one topic for a couple of months. Who is on? BdB. PS: I am also noticing the total absence of the INRIA's expression on this thread. I think the community is extremely motivated to help out the team, but I would like to check whether it is welcome that the community does some thinking about the nameclash issue. Not that I think that we should take over development of O'CaML, but the "-pack" option does not seem to help avoiding nameclash and I don't want to just complain about it... > -----Message d'origine----- > De : Christian Lindig [mailto:lindig@eecs.harvard.edu] > Envoye : dimanche 20 juillet 2003 20:30 > A : Gerd Stolpmann > Cc : BdB; Fernando Alegre; Shawn Wagner; caml-list@inria.fr > Objet : Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?)) > > > On Sun, Jul 20, 2003 at 11:55:49AM +0200, Gerd Stolpmann wrote: > > I have an alternative, the "relational solution". > > 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"] > > This is a fresh idea. But I get the impression that the essence of it is > to decouple the name of a module from the name of the file that contains > it. Somebody suggested already an -alias directive for similar > purposes. > > We have to decide whether we want this decoupling to happen at the level > of the language (i.e. new syntax), or only the level of its > implementation (i.e. new compiler flags). Right now, the mapping of > module names to files is a matter of the compiler and mostly invisible > at the language level. > > -- Christian ------------------- 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