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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 54DBBBBAF for ; Tue, 18 Nov 2008 13:39:57 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUCAOdGIknCpx6vhWdsb2JhbACTWQEBAQoLCgUTvhKCeQ X-IronPort-AV: E=Sophos;i="4.33,624,1220220000"; d="scan'208";a="20079261" Received: from smtpka.univ-orleans.fr (HELO ka.univ-orleans.fr) ([194.167.30.175]) by mail1-smtp-roc.national.inria.fr with ESMTP; 18 Nov 2008 13:39:57 +0100 Received: from smtps.univ-orleans.fr (localhost [127.0.0.1]) by ka.univ-orleans.fr (Postfix) with ESMTP id 17A5512AD4A; Tue, 18 Nov 2008 13:39:57 +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 7333236E60; Tue, 18 Nov 2008 13:39:58 +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:40:00 +0100 Message-Id: <1227012000.6170.94.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 ocaml:01 submodules:01 flatten:01 mutable:01 mutable:01 arraylabels:01 ocamlnet:01 camomile:01 camlp:01 cheers:01 univ-orleans:01 lifo:01 On Tue, 2008-11-18 at 12:34 +0100, Daniel Bünzli wrote: > Le 18 nov. 08 à 11:29, Erkki Seppala a écrit : > > > For example I prefer using the least amount of opening of modules, > > to make it easier to see where the values come from > > Same here. This is why I'm a little bit sceptical about this hierarchy. > > With the current standard library if I suddenly want to use > Int32.of_int, I know I just need to type Int32.of_int in my source. > With your proposal I need to remember that it is in Data.Numeric and > go at the beginning of my file to open it or write > Data.Numeric.Int32.of_int, to me this brings bureaucracy without any > benefit. And lack of bureaucracy is one of the reasons I like ocaml > (and dislike java for example). I forgot to answer that part. In Batteries, for the moment, we decided to keep the module names of the base library as shortcuts to our new modules. Consequently, you can still write your [Int32.of_int] in addition to our new [Int32.print], etc. The old modules are still available as submodules of [Legacy], if needed. Should you wish to flatten the complete hierarchy, assuming that it's possible and that there are no collisions on names, that's also something which you can do quite easily. We even provide some syntactic sugar for this. It's just the matter of writing a file my_batteries.ml along the lines of module Array = Data.Mutable.Array module List = Data.Persistent.List ... module PosixThreads = Control.Concurrency.Threads.Threads module PosixMutex = Control.Concurrency.Threads.Mutex module CoThreads = Control.Concurrency.CoThreads.Threads ... module ArrayExn = Data.Mutable.Array include ExceptionLess (*syntactic sugar*) module ArrayLabels = Data.Mutable.Array include Labels module ArrayCapExn = Data.Mutable.Array.Cap include ExceptionLess module ArrayCapLabels= Data.Mutable.Array.Cap include Labels ... I personally don't like name [ArrayCapLabels] but I can't think of any better name to represent this once we have removed any hierarchy. I personally prefer the hierarchy but, once again, the majority may disagree. So if you believe this is better, the next logical step would be to design a full and consistent list of modules including all the modules which already appear in the current version of Batteries, and with some space left for OCamlnet, OCamlnae, Reins, Camomile, ULex, Camlp4, CoThreads and a few others. I truly mean it, if you can provide us with something you consider more comfortable and as future-proof, we may adopt it. 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.