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=0.0 required=5.0 tests=AWL 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 81FD4BC69 for ; Wed, 26 Sep 2007 00:16:03 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAALol+UbAXQInemdsb2JhbACOLAEBCQo X-IronPort-AV: E=Sophos;i="4.20,297,1186351200"; d="scan'208";a="1777655" Received: from concorde.inria.fr ([192.93.2.39]) by mail2-smtp-roc.national.inria.fr with ESMTP; 26 Sep 2007 00:16:03 +0200 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l8PMFvE0010081 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 26 Sep 2007 00:16:03 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAAgl+UbDuhI+n2dsb2JhbACOLAEBAQEHBAYHCBg X-IronPort-AV: E=Sophos;i="4.20,297,1186351200"; d="scan'208";a="1467407" Received: from mail13.bluewin.ch ([195.186.18.62]) by mail1-smtp-roc.national.inria.fr with ESMTP; 26 Sep 2007 00:16:02 +0200 Received: from [192.168.1.58] (85.2.37.244) by mail13.bluewin.ch (Bluewin 7.3.121) id 46F3820C001123FE for caml-list@inria.fr; Tue, 25 Sep 2007 22:16:02 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <46F961E5.5060302@cs.umd.edu> References: <46F95938.7030107@cs.umd.edu> <17487E59-04F2-4509-87B5-24377B051E9E@epfl.ch> <46F961E5.5060302@cs.umd.edu> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <55A4E82E-3D05-4F79-A8A6-A87905EB4FC8@epfl.ch> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Subject: Cherry-picking modules (was Re: [Caml-list] [ANN] OCaml Reins 0.1 - Persistent Data Structure Library) Date: Wed, 26 Sep 2007 00:16:08 +0200 To: caml-list List X-Mailer: Apple Mail (2.752.2) X-Miltered: at concorde with ID 46F9889D.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bunzli:01 buenzli:01 ocaml:01 unify:01 mli:01 bug:01 unification:01 statically:01 dependencies:01 bug:01 messes:01 dependencies:01 cathedral:98 strive:98 cathedral:98 Le 25 sept. 07 =E0 21:30, Mike Furr a =E9crit : > I've deliberately tried to unify many of the conventions that =20 > people have used to allow users to easily change between data =20 > structure implementations. A major goal of the project is that you =20= > don't have to rely on downloading some random .ml/.mli from =20 > someone's webpage and embed it your project. Instead you just use =20 > the reins library and only have to worry about updating one piece =20 > of software for updates/ bug fixes. While I really like having a central repository and unification of =20 conventions I do like cherry-picking and embedding my modules. =20 Nevertheless I understand and respect your point, maybe it is a =20 matter of opinion/taste. But I'll explain why I like picking. There are libraries that need several tightly dependent modules to =20 provide their service and they should be distributed as libraries =20 since use of one module implies use of the others -- note however =20 that sometimes this is by misdesign e.g. everything can actually be =20 easily and conveniently packed in a single module or some parts can =20 be functorized away to split the distribution. But there are also focused services that can be provided as single, =20 pure caml, modules and these should IMHO be distributed as single =20 modules. I try -- as much as possible -- to embed and statically link =20= dependencies in my projects. Of course if there is a bug in one =20 dependency it means more work for me. But the thing is that by doing =20 so I put the burden and complexity of building my project on me and =20 not on my users. If I do not do so, this burden may be aleviated (or =20 not ?) by using a package management system but this solution messes =20 the environment of my users. There are a lot of useful reusable modules in many projects like =20 extlib, ocamlnae, etc, however they are all tied to their =20 "cathedral" [1] even though these ties are sometimes very small and =20 could be functorized away (or dropped altogheter). Now if I _just_ =20 want to use the Unzip module of extlib, the Cf_tai64 module of =20 ocamlnae and your Patricia set. Why do I have to install these three =20= whole libraries whereas I could simply integrate these three modules =20 in my project ? Having to install them not only puts a burden on potential users, but =20= it also puts a burden on me when I suddenly start to hack my project =20 in another environment which has not all the dependencies installed. =20 In the end I think module integration makes me loose less time =20 because once the build system is setup I have to think about it much =20 less at later times. The alternative solution of embedding the whole =20 libraries is the start of bloat. It also hides the real dependencies =20 which makes it harder for new commers to approach the code base. I think developers of reusable components should try to strive for =20 *focused*, independent modules, even if it means functorization and =20 convention. Eventually it makes it easier for developers to integrate =20= these modules and exchange specific parts if some module poses a =20 problem or better alternatives popup. And while certainly more could be done to try to simplify this style =20 of development (maybe something along the lines of caml-get), I have =20 to say that now that we have been provided with ocamlbuild, the task =20 of integrating pure caml modules is really a breeze -- even if you =20 want to relegate dependencies to a specific directory. Again I'm not for embedding everything in projects, sometimes it is =20 unrealistic. But for exemple I'd systematically do this for data =20 structures, unless of course they are in the standard distribution. Best and thanks again for the work, Daniel [1] btw this was my point about the cathedral, many modules that you =20 have to take as a one-stop-shop-it-all even if you care only for one, =20= not the development style.=20=