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 RAA25510; Tue, 22 Jul 2003 17:29:43 +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 RAA30044 for ; Tue, 22 Jul 2003 17:29:40 +0200 (MET DST) Received: from smtp.mbg.ocn.ne.jp (mbg.ocn.ne.jp [210.190.142.181]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h6MFTdf05870 for ; Tue, 22 Jul 2003 17:29:39 +0200 (MET DST) Received: from localhost (p17141-adsau14honb7-acca.tokyo.ocn.ne.jp [220.106.130.141]) by smtp.mbg.ocn.ne.jp (Postfix) with ESMTP id CD1E31344; Wed, 23 Jul 2003 00:29:36 +0900 (JST) Date: Wed, 23 Jul 2003 00:29:02 +0900 (JST) Message-Id: <20030723.002902.115903192.yoriyuki@mbg.ocn.ne.jp> To: bdbkun@wanadoo.fr Cc: lindig@eecs.harvard.edu, info@gerd-stolpmann.de, benoit.de-boursetty+caml-list@m4x.org, fernando@cc.gatech.edu, shawnw@speakeasy.org, caml-list@inria.fr Subject: Re: [Caml-list] GODI From: Yamagata Yoriyuki In-Reply-To: References: <20030720183027.GB559@eecs.harvard.edu> X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop: caml-list@inria.fr X-Spam: no; 0.00; yamagata:01 yoriyuki:01 caml-list:01 cpan:01 gerd's:01 enforced:01 step-by-step:99 renaming:01 omitted:01 mount:01 stdlib:01 compiler:01 caml:01 hierarchies:01 raises:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: "BdB" Subject: RE: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?)) Date: Tue, 22 Jul 2003 02:01:45 +0200 > 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. So we are going to define global identifies for modules. Well, such a move is neither necessary, nor sufficient for the conflict resolution, unless the policy is strictly enforced, but then it has the own drawback. Global identification is certainly interesting facility, but our problem (the conflict of the name space) raises well before the problem of global identification. Actually, we do not have the method to manage the name space even locally. I think we should tackle this problem by a step-by-step manner, like a) Make a tool consistently renaming the modules. Also, modification of the compiler to "untie" the module name from the file name would be required. b) Incorporate these tools to package management tools. For example, when installing a package, each module in the package is renamed to _. Also, we may need to add the "completion" facilities to the compiler, so that if is omitted, the compiler will automatically search the right module. c) Adopt hierarchical package names, say, Num_Matrix_<....> and enable users to "mount" these hierarchies to nodes they choose. So, for example, some users choose stdlib resides the top level, while some users mount them under Stdlib... and so on. I think many people have similar ideas. -- Yamagata Yoriyuki ------------------- 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