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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 5B452BBAF for ; Tue, 18 Nov 2008 15:40:33 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgCABdiIklDz4HegWdsb2JhbACTWAEBFiK+SYJ5 X-IronPort-AV: E=Sophos;i="4.33,625,1220220000"; d="scan'208";a="19294669" Received: from fettunta.fettunta.org ([67.207.129.222]) by mail3-smtp-sop.national.inria.fr with ESMTP; 18 Nov 2008 15:40:32 +0100 Received: from usha.takhisis.invalid (unknown [10.17.0.18]) by fettunta.fettunta.org (Postfix) with ESMTP id A39261812E for ; Tue, 18 Nov 2008 14:40:30 +0000 (UTC) Received: by usha.takhisis.invalid (Postfix, from userid 1000) id E353461A4; Tue, 18 Nov 2008 15:40:27 +0100 (CET) Date: Tue, 18 Nov 2008 15:40:27 +0100 From: Stefano Zacchiroli To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Wanted: your feedback on the hierarchy of OCaml Batteries Included Message-ID: <20081118144027.GA11221@usha.takhisis.invalid> References: <218682.78372.qm@web111513.mail.gq1.yahoo.com> <1227018213.6170.122.camel@Blefuscu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1227018213.6170.122.camel@Blefuscu> User-Agent: Mutt/1.5.18 (2008-05-17) X-Spam: no; 0.00; zacchiroli:01 zack:01 ocaml:01 0100,:01 mutable:01 mutable:01 cheers:01 zacchiroli:01 postdoc:01 zack:01 einstein:98 blog:98 dietro:98 c'e:98 sempre:98 On Tue, Nov 18, 2008 at 03:23:33PM +0100, David Teller wrote: > On Tue, 2008-11-18 at 05:31 -0800, Dario Teixeira wrote: > > Paraphrasing Einstein, I think the hierarchy should be as flat > > as possible, but no flatter. For example, I see no reason to > > materialise in the hierarchy the separation between persistent > > and mutable data structures. The should be a documentation > > issue. However, and as you noted, there are cases where some > > hierarchisation may remove namespace clutter and allow for > > better code reuse. > > Duly noted. As you may see on our candidate replacement hierarchy, we > intend to merge Data.Persistent and Data.Mutable into Data.Containers. More generally, I would like to advertise a bit more the proposed *replacement* hierarchy reported at the bottom of David's blog post [1]; do a text search for "One possible replacement" and start reading from there. Several problems with the current hierarchy which have been pointed out in this thread were notice by ourselves as well, and are already, at least partly, solved by the proposed new hierarchy. Cheers. [1] http://dutherenverseauborddelatable.wordpress.com/2008/11/18/batteries-hierarchy/ -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime