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=4.2 required=5.0 tests=AWL,DNS_FROM_RFC_POST, DNS_FROM_SECURITYSAGE,SPF_NEUTRAL 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 6236EBBAF for ; Tue, 18 Nov 2008 14:26:04 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUBAHNRIklC+VytkGdsb2JhbACTGz4BAQEBCQkMBxEDsi+LdAEDAQOCdoIN X-IronPort-AV: E=Sophos;i="4.33,625,1220220000"; d="scan'208";a="31562610" Received: from ug-out-1314.google.com ([66.249.92.173]) by mail4-smtp-sop.national.inria.fr with ESMTP; 18 Nov 2008 14:26:04 +0100 Received: by ug-out-1314.google.com with SMTP id k3so229424ugf.4 for ; Tue, 18 Nov 2008 05:26:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=l6tKYN/P1GCrdNM1Go2rpjVCYSbLTjJ3FLFB7C5suZQ=; b=H9JQqJQEyP6uMuiAuhrB9x/ef2p97hWxu49tGzOxorax8N5YkVrT8X4FX/ulFk+zj6 0pbTLI2LlcVtu31yyvl5n/wLl5PXJSYCZZBRa8BgF/8k8C4l6r5xpFFNPPX/0qtHoMkG IDtqoR+VGuG1cGlatliDzmbRaGpT3Kt6bI4Gw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=uswO5OVmYKaMKuAKfca84rg/DVuFBx/NMTth/1mBgP0n26MkjgK5I3otC3ffnHYLmP RuD/vyfUyep9DrLYNK1ggoPDbXA8vHO4yxRrt3VvjOAgjdF2xmVIdu9x96PjL8hXz3NL QfXN65F1G15gf/7D81ji/gWpL7YtAM4xXfmkA= Received: by 10.86.4.2 with SMTP id 2mr2939818fgd.43.1227014763298; Tue, 18 Nov 2008 05:26:03 -0800 (PST) Received: from ?192.168.1.34? (235-11.77-83.cust.bluewin.ch [83.77.11.235]) by mx.google.com with ESMTPS id l12sm4867416fgb.6.2008.11.18.05.26.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Nov 2008 05:26:02 -0800 (PST) Message-Id: <6DE1668B-06D3-4EC7-8B59-0996B814C58B@erratique.ch> From: =?ISO-8859-1?Q?Daniel_B=FCnzli?= To: OCaml List In-Reply-To: <1227010539.6170.72.camel@Blefuscu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [Caml-list] Wanted: your feedback on the hierarchy of OCaml Batteries Included Date: Tue, 18 Nov 2008 14:24:59 +0100 References: <1227002178.6170.25.camel@Blefuscu> <20081118100625.GA25627@annexia.org> <421532A1-E2CA-404F-8387-E11DA9B3DE79@erratique.ch> <1227010539.6170.72.camel@Blefuscu> X-Mailer: Apple Mail (2.929.2) Sender: =?UTF-8?B?RGFuaWVsIELDvG56bGk=?= X-Spam: no; 0.00; bunzli:01 buenzli:01 ocaml:01 toplevel:01 ad-hoc:01 toplevel:01 cpan:01 cpan:01 syntax:01 inherently:01 threads:01 threads:01 maintainers:01 caml-list:01 hierarchical:01 Le 18 nov. 08 =E0 13:15, David Teller a =E9crit : > But, to keep things ordered, we will still need modules > [Threads.Threads], [Threads.Mutex], [Threads.RMutex]... > [CoThreads.Threads], [CoThreads.Mutex]... and, well, that's a =20 > hierarchy > already. If you include in batteries an external package that has its own =20 hierarchy and is designed to be opened I don't mind having that =20 hierarchy. In that case you can just add the new toplevel entry =20 CoThread. And if I want to use CoThread, I just open CoThreads, not =20 Control.Concurrency.CoThreads. Just try to keep it as flat as =20 possible, don't try to force modules in an ad-hoc hierarchical =20 taxonomy to try to sort out modules. I don't care if the toplevel list =20= of modules is three hundred pages long if there is an efficient mean =20 to access their documentation (like tags). I do however care a lot if =20= it becomes bureaucratic to be able to _use_ a module in my code. Le 18 nov. 08 =E0 13:22, Richard Jones a =E9crit : > Easy - look at CPAN[1]. If you want to scale a project you have to =20= > make decisions that allow a distributed network of people to =20 > cooperate, without needing too much central coordination. But (unfortunately, sorry to repeat that) Batteries is not a CPAN like =20= initiative. It aims at giving a library of modules/syntax extensions =20 selected by the library maintainers, as such it is inherently =20 centralized and I don't think that questions (1) or (2) are actually =20 pertinent for the project. Best, Daniel