From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.7 required=5.0 tests=AWL,DNS_FROM_SECURITYSAGE, SPF_FAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 6C53CBBAF for ; Tue, 18 Nov 2008 13:22:51 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgCADhCIknAXQIngWdsb2JhbACTWQEBFiK+EoJ5 X-IronPort-AV: E=Sophos;i="4.33,624,1220220000"; d="scan'208";a="31560169" Received: from concorde.inria.fr ([192.93.2.39]) by mail4-smtp-sop.national.inria.fr with ESMTP; 18 Nov 2008 13:22:50 +0100 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id mAICMmpo003692 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 18 Nov 2008 13:22:50 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgCADhCIklQRFuwgWdsb2JhbACTWQEBFiK+EoJ5 X-IronPort-AV: E=Sophos;i="4.33,624,1220220000"; d="scan'208";a="17320183" Received: from furbychan.cocan.org ([80.68.91.176]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 18 Nov 2008 13:22:50 +0100 Received: from rich by furbychan.cocan.org with local (Exim 4.63) (envelope-from ) id 1L2PbV-0003vP-7V; Tue, 18 Nov 2008 12:22:49 +0000 Date: Tue, 18 Nov 2008 12:22:49 +0000 To: David Teller Cc: OCaml Subject: Re: [Caml-list] Wanted: your feedback on the hierarchy of OCaml Batteries Included Message-ID: <20081118122248.GG27367@annexia.org> References: <1227002178.6170.25.camel@Blefuscu> <20081118100625.GA25627@annexia.org> <1227007048.6170.35.camel@Blefuscu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1227007048.6170.35.camel@Blefuscu> User-Agent: Mutt/1.5.13 (2006-08-11) From: Richard Jones X-Miltered: at concorde with ID 4922B398.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 0100,:01 cpan:01 cpan:01 coupling:01 wrote:01 naming:01 naming:01 caml-list:01 data:02 modules:02 module:03 module:03 hierarchy:03 rename:04 On Tue, Nov 18, 2008 at 12:17:28PM +0100, David Teller wrote: > This raises two questions: > 1) how important is it to allow third-party modules to extend the > namespace? > 2) how important is it to offer a uniform package structure (where > levels are always separated by '.' rather than some level by '.' and > some by '_')? > > For the moment, we have considered point 1 not very important and point > 2 a little more. There are several reasons to disregard point 1. Among > these, clarity of origin (as in "is this module endorsed by Batteries or > not?") and documentation issues (as in "gosh, this module pretends to be > part of [Data] but I can't find the documentation anywhere in the > documentation of Batteries, wtf?"). > > Do you believe that we should have chosen otherwise? Easy - look at CPAN[1]. If you want to scale a project you have to make decisions that allow a distributed network of people to cooperate, without needing too much central coordination. CPAN is a great example of this loose coupling because packages make their own decision about naming (albeit they can become "official" later - but they won't need to rename unless there is an actual naming conflict). If the problem is documentation or provenance of packages, then add a mechanism to solve that problem. Perl also solves this through an existing, lightweight, distributed mechanism (a standard location to install man-pages, and a standard man-page format and man-page generating mechanism -- POD). Rich. [1] http://www.cpan.org/ -- Richard Jones Red Hat