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.1 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 E212ABBAF for ; Tue, 18 Nov 2008 13:15:35 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoBABdBIknCpx6wmWdsb2JhbACTWQEBAQEBCAsKBxG+CoJ5 X-IronPort-AV: E=Sophos;i="4.33,624,1220220000"; d="scan'208";a="17319864" 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 13:15:35 +0100 Received: from smtps.univ-orleans.fr (localhost [127.0.0.1]) by min.univ-orleans.fr (Postfix) with ESMTP id 5F70012B4EB; Tue, 18 Nov 2008 13:15:35 +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 E453C36E61; Tue, 18 Nov 2008 13:15:36 +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: <421532A1-E2CA-404F-8387-E11DA9B3DE79@erratique.ch> References: <1227002178.6170.25.camel@Blefuscu> <20081118100625.GA25627@annexia.org> <421532A1-E2CA-404F-8387-E11DA9B3DE79@erratique.ch> Content-Type: text/plain; charset=utf-8 Date: Tue, 18 Nov 2008 13:15:39 +0100 Message-Id: <1227010539.6170.72.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 ocaml:01 submodules:01 arraylabels:01 listlabels:01 morelabels:01 foo:01 read-only:01 arrays:01 variants:01 cheers:01 univ-orleans:01 On Tue, 2008-11-18 at 12:34 +0100, Daniel Bünzli wrote: >Besides Hierarchies are anyway limited in their descriptive power and >one day you'll find something that will fit in two places, Rope is >already an example being both Data.Persistent and Data.Text. That's correct, there are plenty of modules which could fit in different places. For the moment, we decided that every module should appear only in one place. However, we could easily change this -- in fact, to allow this, we only need to alter our documentation generator. > Thus my proposal would be to _present_ them as a hierarchy (but even > here a mean to tag/browse the modules with/by keywords would do a > better job) but keep the actual module structure of Batteries as flat > as possible, everything just under the toplevel Batteries. When I code > I really don't want to have to think about all these open directives > that essentially bring nothing. Browsing by keywords sounds like an interesting idea. I'm adding this to our TODO list. Of course, the next step will be to actually add these keywords and that's going to be much longer if we intend to tag all values. However, we disagree on the necessity of a hierarchy. There are two good reasons why the base library of OCaml doesn't have a hierarchy (almost): it's small and there are almost no redundancies between modules. Neither is true for Batteries. For an example of this redundancy, consider threads. For the moment, we have five thread-related modules: [Threads], [Mutex], [RMutex], [Condition] and [Event]. These modules, which are essentially the same modules as those of the base library, are all submodules of [Control.Concurrency.Threads]. Now, I personally like [Control.Concurrency] but I agree that this is debatable. The reason why we group these modules into [Threads] is because sooner or later, we are going to have four or five other thread-related modules called [Threads], [Mutex], [Condition], [Event] and perhaps [RMutex]. These modules will get into [Control.Concurrency.CoThreads]. They won't replace the first batch, they will exist side-by-side. Of course, we could trim the hierarchy and remove [Control.Concurrency] -- trimming the hierarchy is the main reason for launching this thread, incidentally. 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. coThreads is not an exceptional case, mind you. We may end up with two definitions of [Graphics], several data structures with the same name but different purposes, etc. There's also the issue of labels and other partial redefinitions of modules. The OCaml base library defines [Array]/[ArrayLabels], [List]/[ListLabels], [Map]/[MoreLabels.MapLabels] etc. In Batteries Included, we define [Array], [Array.Labels], [List], [List.Labels], which clutters less the list of modules and makes for something more consistent, especially since [FooLabel] is not the only kind of "module [Foo] with a variant": we also have [Array.ExceptionLess], for operations without exceptions, and [Array.Cap] for read-only/write-only arrays. Other variants may still appear. Do you see any better way of managing the complexity of all this? 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.