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.4 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE 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 85FA1BC69 for ; Wed, 26 Sep 2007 20:45:38 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAAtG+kbAXQImh2dsb2JhbACOMAEBAQgKJw X-IronPort-AV: E=Sophos;i="4.21,198,1188770400"; d="scan'208";a="1834861" Received: from discorde.inria.fr ([192.93.2.38]) by mail2-smtp-roc.national.inria.fr with ESMTP; 26 Sep 2007 20:45:38 +0200 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l8QIjbPL010929 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 26 Sep 2007 20:45:38 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAABJF+kaACH6Ci2dsb2JhbACOMAEBARk X-IronPort-AV: E=Sophos;i="4.21,198,1188770400"; d="scan'208";a="1534109" Received: from lb-nat-3.cs.umd.edu (HELO dispatch.cs.umd.edu) ([128.8.126.130]) by mail1-smtp-roc.national.inria.fr with ESMTP; 26 Sep 2007 20:45:37 +0200 Received: from [172.16.4.16] (bruce.cs.umd.edu [172.16.4.16]) by dispatch.cs.umd.edu (8.13.1/8.12.5) with ESMTP id l8QIjVxQ022093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Sep 2007 14:45:31 -0400 Message-ID: <46FAA8E6.3090501@cs.umd.edu> Date: Wed, 26 Sep 2007 14:45:58 -0400 From: Mike Furr User-Agent: Icedove 1.5.0.12 (X11/20070606) MIME-Version: 1.0 To: caml-list List Subject: Re: Cherry-picking modules (was Re: [Caml-list] [ANN] OCaml Reins 0.1 - Persistent Data Structure Library) References: <46F95938.7030107@cs.umd.edu> <17487E59-04F2-4509-87B5-24377B051E9E@epfl.ch> <46F961E5.5060302@cs.umd.edu> <55A4E82E-3D05-4F79-A8A6-A87905EB4FC8@epfl.ch> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.399, required 5, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-CSD-MailScanner-From: furr@cs.umd.edu X-Miltered: at discorde with ID 46FAA8D2.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 bunzli:01 re-use:01 bazar:01 camomile:01 coupling:01 trade-off:01 implements:01 orphaned:01 orphaned:01 pointers:01 strive:98 cathedral:98 cathedral:98 wrote:01 Daniel Bünzli wrote: >> But you should start by raising the bar for re-use, not lowering it. > > I don't know how I should interpret this (I don't understand the meaning). I only meant that we should strive to use the "right" solution, even if that means a little more work for the time being since it will hopefully improve things in the long run. > For me the bar is too high for sharing. We need more lightweight ways of > doing so, let the real bazar be and eventually good components will be > selected. Maybe if there had been a convenient, agreed bupon, > module-based, *localized* (in the sense not system wide) and distributed > package system you wouldn't be the the xth person to implement avl > trees. For example go look into Camomile there's an implementation there. Its hard for me to conceptualize how such a distributed system would work and so I can't really comment if it would in fact be a better system. However, one problem I wanted to tackle was that while I would be the xth person to implement avl trees, there will be NO x+1th person. Reins is one (possible) solution to that. > But I agree with you tight coupling can also be beneficial, it's a > trade-off. However maybe (I don't know) reins could have been split > w.r.t to the different kind of semantic data structure (set, list, map). > It depends on the deal of code sharing that actually occurs between > them. The unit tests could have been done as a separate project that > requires these smaller packages. etc. Currently, the unit tests are just part of the build and are not installed. However, since they are parameterized, perhaps I should distribute them as a second (optional) library so that anyone who implements a data structure which matches the signatures there can use them too. Thanks for the idea. > I strongly believe that smaller > components are more manageable in the long term. Because whenever they > break or become orphaned it becomes easier for third-parties to > understand them and maintain them alive. As a counter point, smaller components may mean that fewer people are interested in each component and thus are more likely to become orphaned as individuals than as part of a larger collection. I think your idea is interesting, but I haven't seen any anecdotal evidence of it actually being better than the "cathedral" approach. Pointers/references to such things would be welcome. > But hey, I don't want to look like I'm grumling about reins, it sure > looks great and usefull. So I think I better stop this discussion here. I don't think you are, and in fact, as library designer/maintainer its great to get feedback on how people feel about the current status quo of library management. If someone were to build such a distributed localized module collection, I would love to see the code from reins in there. In the time being, I think the cathedral approach should work quite well. Thanks for the dialogue... and now back to hacking. -m