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 05D8EBBAF for ; Wed, 19 Nov 2008 14:36:57 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgCAIelI0lDz4HegWdsb2JhbACTVwEBFiK+a4J5 X-IronPort-AV: E=Sophos;i="4.33,631,1220220000"; d="scan'208";a="19332694" Received: from fettunta.fettunta.org ([67.207.129.222]) by mail3-smtp-sop.national.inria.fr with ESMTP; 19 Nov 2008 14:36:57 +0100 Received: from usha.takhisis.invalid (unknown [10.17.0.18]) by fettunta.fettunta.org (Postfix) with ESMTP id DC85518151 for ; Wed, 19 Nov 2008 13:36:55 +0000 (UTC) Received: by usha.takhisis.invalid (Postfix, from userid 1000) id 2F7776875; Wed, 19 Nov 2008 14:36:52 +0100 (CET) Date: Wed, 19 Nov 2008 14:36:52 +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: <20081119133652.GB1646@usha.takhisis.invalid> References: <1227002178.6170.25.camel@Blefuscu> <20081118100625.GA25627@annexia.org> <421532A1-E2CA-404F-8387-E11DA9B3DE79@erratique.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <421532A1-E2CA-404F-8387-E11DA9B3DE79@erratique.ch> User-Agent: Mutt/1.5.18 (2008-05-17) X-Spam: no; 0.00; zacchiroli:01 zack:01 ocaml:01 0100,:01 bunzli:01 compiler:01 iirc:01 clashes:01 cheers:01 zacchiroli:01 postdoc:01 zack:01 dietro:98 c'e:98 sempre:98 On Tue, Nov 18, 2008 at 12:34:28PM +0100, Daniel Bünzli wrote: >> 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. Well, the problem of not knowing where a value comes from is more a tool problem, than an argument against hierarchies. The compiler knows where a value comes from, it is only hard to get this information back. IIRC one of this year OSP addressed precisely that problem. > 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. Yes, but that's not a good reason to give up hierarchies completely. The advantage of hierarchies is to have less top-level roots, which reduce the likelihood of clashes with external libraries. Even though in some cases you might need to choose among two different places, it is rarely the case in practice. Also remember that the Batteries hierarchy was not meant to allocate *all* existing libraries into a common hierarchy, that interpretation came from Rich's comment. So the real question is, according to what you currently see in the hierarchy, do you like it or not? Do you something placed in weird places? Cheers. -- 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