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 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 E1165BC6B for ; Fri, 25 Jan 2008 08:25:57 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAACUdmUfUGyodimdsb2JhbACQJAEBAQgEBgcKCAkHnis X-IronPort-AV: E=Sophos;i="4.25,249,1199660400"; d="scan'208";a="8348175" Received: from smtp3-g19.free.fr ([212.27.42.29]) by mail3-smtp-sop.national.inria.fr with ESMTP; 25 Jan 2008 08:25:57 +0100 Received: from smtp3-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp3-g19.free.fr (Postfix) with ESMTP id 4806217B53C; Fri, 25 Jan 2008 08:25:57 +0100 (CET) Received: from [192.168.0.3] (rke75-3-82-229-183-156.fbx.proxad.net [82.229.183.156]) by smtp3-g19.free.fr (Postfix) with ESMTP id 1D2AF17B52B; Fri, 25 Jan 2008 08:25:56 +0100 (CET) Message-ID: <47998DE1.1070503@frisch.fr> Date: Fri, 25 Jan 2008 08:21:05 +0100 From: Alain Frisch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jon Harrop , caml-list Subject: Re: [Caml-list] Working around the brittle bindings problem References: <200801242140.06785.jon@ffconsultancy.com> In-Reply-To: <200801242140.06785.jon@ffconsultancy.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; frisch:01 frisch:01 bindings:01 bindings:01 abstracted:01 dependencies:01 functor:01 stdlib:01 functor:01 constructors:01 camlp:01 adc:98 wrote:01 parameterize:01 caml-list:01 Jon Harrop wrote: > Just occurred to me that one possible solution to our brittle bindings problem > might be to parameterize the whole library over the external calls that are > made. Indeed, that's a brilliant idea. Btw, it has been suggested to you a few weeks ago. http://groups.google.com/group/fa.caml/msg/cc6adc628b396b06: > What you can do is to ship your library as a single module abstracted > over all its dependencies (that is, a functor which takes as arguments > modules from the stdlib and other dependent libraries). You can put in > the interface whatever you expect from these modules, so the same > functor could be used with future versions if they only add new fields > (but not new constructors or record fields, for instance). Again, some > Camlp4 hack could somewhat automate this. -- Alain