From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 3EBE4BB9C for ; Thu, 1 Dec 2005 02:52:24 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id jB11qNcd017383 for ; Thu, 1 Dec 2005 02:52:23 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id CAA26128 for ; Thu, 1 Dec 2005 02:52:23 +0100 (MET) Received: from comtv.ru (mail.comtv.ru [217.10.32.19]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jB11qMRh022416 for ; Thu, 1 Dec 2005 02:52:22 +0100 X-UCL: actv Received: from av1474.oops ([10.0.66.9] verified) by comtv.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP id 106918063; Thu, 01 Dec 2005 04:52:23 +0300 Date: Thu, 1 Dec 2005 04:53:43 +0300 (MSK) From: malc X-X-Sender: malc@home.oyster.ru To: Jacques Garrigue Cc: daniel.buenzli@epfl.ch, caml-list@inria.fr Subject: Re: [Caml-list] How to compile different implementations of the same lib In-Reply-To: <20051201.100719.07647797.garrigue@math.nagoya-u.ac.jp> Message-ID: References: <20051130.211930.102965761.garrigue@math.nagoya-u.ac.jp> <4F70401E-AE91-4E5E-AF67-70FBDCC7C353@epfl.ch> <20051201.100719.07647797.garrigue@math.nagoya-u.ac.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Miltered: at nez-perce with ID 438E5757.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 438E5756.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; malc:01 malc:01 pulsesoft:01 caml-list:01 lib:01 cmi's:01 mli:01 cmi:01 compiler:01 inlining:01 cmx:01 functor:01 cmx:01 trivial:01 functor:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.3 On Thu, 1 Dec 2005, Jacques Garrigue wrote: > Yes, that's the idea. > I should have been more specific: > In order to create a clean separation between the library and the > client, such that you will be able to change the implementation of the > library, you must write .mli's for all the modules the library > exports, and compile the client with only the .cmi's in the path. > Note of course that the .mli/.cmi must also be copied to the directory > where you compile the library (the compiler only looks for them there > when compiling the .ml). > > A result is that there cannot be any inlining between client and > library. Actually, this is even worse than that: this also prevents > direct function calls, as the concrete information about functions is > also in the .cmx. All calls will have to go through closures. Just > like when you call a function received as parameter, or inside a > functor. A long while ago i wrote an unliner for .cmx to fight precisely this problem, was quite trivial too, not that i ever understood the full implications of this ofcourse. > > This suggests the other evident alternative: write the client as a > functor. This will not be slower! But this can be more painful if > there are several modules in the client... -- mailto:malc@pulsesoft.com