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.2 required=5.0 tests=AWL,DNS_FROM_SECURITYSAGE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 0F5FBBBAF for ; Tue, 18 Nov 2008 15:46:00 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoBADNkIknCpx6wmWdsb2JhbACTWAEBAQEBCAsKBxG+T4J5 X-IronPort-AV: E=Sophos;i="4.33,625,1220220000"; d="scan'208";a="17326968" Received: from smtpmin.univ-orleans.fr (HELO min.univ-orleans.fr) ([194.167.30.176]) by mail2-smtp-roc.national.inria.fr with ESMTP; 18 Nov 2008 15:45:59 +0100 Received: from smtps.univ-orleans.fr (localhost [127.0.0.1]) by min.univ-orleans.fr (Postfix) with ESMTP id 9F21C12B4E4; Tue, 18 Nov 2008 15:45:59 +0100 (CET) Received: from [192.168.0.12] (ras75-4-82-235-58-110.fbx.proxad.net [82.235.58.110]) by smtps.univ-orleans.fr (Postfix) with ESMTP id 534A336E62; Tue, 18 Nov 2008 15:46:01 +0100 (CET) Subject: Re: [Caml-list] Wanted: your feedback on the hierarchy of OCaml Batteries Included From: David Teller To: Daniel =?ISO-8859-1?Q?B=FCnzli?= Cc: OCaml List In-Reply-To: <6DE1668B-06D3-4EC7-8B59-0996B814C58B@erratique.ch> References: <1227002178.6170.25.camel@Blefuscu> <20081118100625.GA25627@annexia.org> <421532A1-E2CA-404F-8387-E11DA9B3DE79@erratique.ch> <1227010539.6170.72.camel@Blefuscu> <6DE1668B-06D3-4EC7-8B59-0996B814C58B@erratique.ch> Content-Type: text/plain; charset=utf-8 Date: Tue, 18 Nov 2008 15:46:02 +0100 Message-Id: <1227019562.6170.144.camel@Blefuscu> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 8bit X-Spam: no; 0.00; ocaml:01 univ-orleans:01 0100,:01 toplevel:01 ad-hoc:01 toplevel:01 submodules:01 functors:01 camomile:01 uchar:01 uchar:01 hypothetical:01 cpan:01 cpan:01 syntax:01 On Tue, 2008-11-18 at 14:24 +0100, Daniel Bünzli wrote: > Le 18 nov. 08 à 13:15, David Teller a écrit : > > > 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 > > hierarchy > > already. > > If you include in batteries an external package that has its own > hierarchy and is designed to be opened I don't mind having that > hierarchy. > > In that case you can just add the new toplevel entry > CoThread. And if I want to use CoThread, I just open CoThreads, not > Control.Concurrency.CoThreads. Just try to keep it as flat as > possible, don't try to force modules in an ad-hoc hierarchical > taxonomy to try to sort out modules. I don't care if the toplevel list > of modules is three hundred pages long if there is an efficient mean > to access their documentation (like tags). I do however care a lot if > it becomes bureaucratic to be able to _use_ a module in my code. I concur that tags make a considerable difference. But let us return to threads for one second. There is a very good reason to have two distinct modules [Threads] and [CoThreads] with 4-5 submodules each: functors. Assuming [Threads] and [CoThreads] implement the same interface -- which they do -- I can write a module which takes as argument either [Threads], [CoThreads] or [WhateverThreads] and produces a pseudo-concurrent/truly concurrent/whatever implementation of an algorithm. The same thing could apply to latin-1 strings vs. Unicode strings (this is essentially what happens in Camomile). Now, there are certainly several possibilities. Here's one which doesn't involve a deep hierarchy: * [Thread], [Mutex], [Concurrent], [Event] remain top-level modules * [Threads] is also a top-level module, which contains aliases to [Thread], [Mutex], [Concurrent], [Event] * [CoThreads] is also a top-level module, which contains its own implementations of [Thread], [Mutex], [Concurrent], [Event] We could do the same for strings * [String], [Char], [Rope], [UChar] remain top-level modules * we introduce a new module [Strings] containing [String] and [Char] * we introduce another new module [UStrings] containing an alias [String] to [Rope] and an alias [Char] to [UChar] And for numbers * [Float], [Int], [SafeInt], [BigInt] and hypothetical [SafeFloat] and [BigFloat] (don't ask me what a BigFloat is supposed to be) remain top-level modules * we introduce a new module [Numeric] containing [Float] and [Int] * we introduce a new module [SafeNumeric] containing [SafeFloat] aliased as [Float], [SafeInt] aliased as [Int] * we introduce a new module [BigNumeric] containing [BigFloat] aliased as [Float], [BigInt] aliased as [Int] etc. To me, this seems like the only way to combine no hierarchy and modularity. However, I have the nasty feeling that this is going to end up messy, cluttered and otherwise both unmaintainable and unusable (despite tags). > > Le 18 nov. 08 à 13:22, Richard Jones a écrit : > > > 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. > > But (unfortunately, sorry to repeat that) Batteries is not a CPAN like > initiative. It aims at giving a library of modules/syntax extensions > selected by the library maintainers, as such it is inherently > centralized and I don't think that questions (1) or (2) are actually > pertinent for the project. No, we're not CPAN. If someone wishes to build a CPAN, please feel free to do it. That may actually be easier to do once Batteries 1.0 has landed. However, Richard's remark remains interesting. So perhaps redesigning Batteries to have an open namespace structure is a good idea. Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations.