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.5 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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 19C29BC69 for ; Wed, 26 Sep 2007 17:32:54 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAIsY+kaACICyh2dsb2JhbACOLwEBAQgKJw X-IronPort-AV: E=Sophos;i="4.20,302,1186351200"; d="scan'208";a="3288425" Received: from concorde.inria.fr ([192.93.2.39]) by mail3-smtp-sop.national.inria.fr with ESMTP; 26 Sep 2007 17:32:53 +0200 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l8QFWmnP019464 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 26 Sep 2007 17:32:53 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAIsY+kaACICyh2dsb2JhbACOLwEBAQgKJw X-IronPort-AV: E=Sophos;i="4.20,302,1186351200"; d="scan'208";a="3288423" Received: from flyer.cs.umd.edu ([128.8.128.178]) by mail3-smtp-sop.national.inria.fr with ESMTP; 26 Sep 2007 17:32:52 +0200 Received: from loompa.cs.umd.edu (loompa.cs.umd.edu [128.8.128.63]) by flyer.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id l8QFWpVB005716 for ; Wed, 26 Sep 2007 11:32:51 -0400 Received: from localhost (localhost [127.0.0.1]) by loompa.cs.umd.edu (8.13.8+Sun/8.12.5) with ESMTP id l8QFWnh2012096 for ; Wed, 26 Sep 2007 11:32:51 -0400 (EDT) Date: Wed, 26 Sep 2007 11:32:49 -0400 (EDT) From: Michael Furr X-X-Sender: furr@loompa To: caml-list List Subject: Re: Cherry-picking modules (was Re: [Caml-list] [ANN] OCaml Reins 0.1 - Persistent Data Structure Library) In-Reply-To: <55A4E82E-3D05-4F79-A8A6-A87905EB4FC8@epfl.ch> Message-ID: 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> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1804928587-1190819426=:10669" Content-ID: X-Miltered: at concorde with ID 46FA7BA0.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 unreadable:01 mime-aware:01 bunzli:01 ocaml:01 dependences:01 deps:01 re-use:01 mixin:01 functors:01 swapped:01 lgpl:01 cheers:01 -mike:01 2007,:98 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1804928587-1190819426=:10669 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: On Wed, 26 Sep 2007, Daniel B=FCnzli wrote: > There are a lot of useful reusable modules in many projects like extlib,= =20 > ocamlnae, etc, however they are all tied to their "cathedral" [1] even th= ough=20 > these ties are sometimes very small and could be functorized away (or dro= pped=20 > altogheter). Now if I _just_ want to use the Unzip module of extlib, the= =20 > Cf_tai64 module of ocamlnae and your Patricia set. Why do I have to inst= all=20 > these three whole libraries whereas I could simply integrate these three= =20 > modules in my project ? Why should you not? There is no good reason to not use the entire library= =20 instead of just pulling out a single funciton. I think you need to separate who are *developers* and who are *users*.=20 Users are those which you should not depend on having an OCaml development= =20 environment intalled. This could be users of a stand-alone app, or=20 perhaps coders using felix. When you distribute your software to them, it= =20 will be in binary form, and you should take care to ensure this is as easy= =20 as possible (especially if you're on a platform like windows). However,=20 this does not require you to keep them in your own source tree. For *developers*, you should have every expectation that they can install= =20 a sufficient environment themselves. No OCaml build system is that bad=20 (especially compared to other languages) and I expect *every* user of my=20 library to be able to build its dependences (or, more realistically,=20 install a package manager to build the deps for them). > 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 problem= =20 > or better alternatives popup. But you should start by raising the bar for re-use, not lowering it. Use= =20 the libraries like you *should* be able to do. If developers find this=20 too difficult to use, tools will follow. Rely on the bazaar. > Again I'm not for embedding everything in projects, sometimes it is=20 > unrealistic. But for exemple I'd systematically do this for data structur= es,=20 > unless of course they are in the standard distribution. There is a significant advantage to combining various data structures into= =20 a single package. For one, there is a lot of room for code sharing. A=20 lot of the functionality of data structures can be implemented in terms of= =20 a few small functions. (For instance, to_string is easily implemented=20 with fold). Using mixin modules to extend these to complete=20 implemetations saves a lot of redundant code. Also, reins runs over 600=20 unit tests, but there certainly aren't 600 separate tests written in the=20 source. It uses a functors to apply to the same tests to different data=20 structures. This ensures that all of the data structures are=20 observationally equivalent when they implement the same interface (which=20 is especially useful for ensuring they all throw the same exception, for=20 instance). Finally, choosing a single data structure at the beginning of your project= =20 and embedding it in your source tree forces you to always use that data=20 structure. One of the advantages of Reins is that it includes different=20 implementations that can be swapped out. If you decide you would rather=20 using a a list with fast concatenation rather than fast cons, its a one=20 line change. You don't have to go find the software, build it, ensure it= =20 has the same interface, ensure it behaves the same way, add it to your=20 source tree, add it to your build system, and then change your uses of it. Of course, the software is LGPL for a reason. If you want to pull out=20 parts of it, you are certainly welcome to do so. I just won't recommend=20 that path to anyone. Cheers, -mike ---559023410-1804928587-1190819426=:10669--