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 0C2FABB81 for ; Fri, 2 Dec 2005 00:48:01 +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 jB1Nm0eH017285 for ; Fri, 2 Dec 2005 00:48:00 +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 AAA15643 for ; Fri, 2 Dec 2005 00:47:59 +0100 (MET) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jB1NlvWc014561 for ; Fri, 2 Dec 2005 00:47:58 +0100 Received: from rosella (ppp33-4.lns1.syd6.internode.on.net [59.167.33.4]) by smtp3.adl2.internode.on.net (8.12.9/8.12.6) with ESMTP id jB1NlaiM047445; Fri, 2 Dec 2005 10:17:47 +1030 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] How to compile different implementations of the same lib From: skaller To: Richard Jones Cc: caml-list@inria.fr In-Reply-To: <20051201200944.GA30251@furbychan.cocan.org> 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> <438F2CE5.9030105@univ-savoie.fr> <1133459647.9266.20.camel@rosella> <20051201200944.GA30251@furbychan.cocan.org> Content-Type: text/plain Date: Fri, 02 Dec 2005 10:47:35 +1100 Message-Id: <1133480856.9266.43.camel@rosella> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 438F8BB0.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 438F8BAD.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 lib:01 cmx:01 cmx:01 pointer:01 lexically:01 ocaml:01 ocaml:01 'x':01 pointer:01 'library':01 plagues:98 wrote:01 heap:01 sourceforge: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.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Thu, 2005-12-01 at 20:09 +0000, Richard Jones wrote: > I don't quite understand this. I get that if the .cmx isn't > available, then one obviously cannot inline the code. But why is it > that you cannot use a simple call instruction even if the .cmx isn't > available? A function is not a piece of code. It is a piece of code plus an object which together are called a closure. The object represents the environment. It is probably easier to understand the Felix representation: a function is a C++ class with an apply method. The class has other members -- local variables of the function, and a pointer to local variables of the function containing it .. etc. This object is allocated on the heap. For example: let f x = let g y = x + y g ;; g 42 ;; here, when you call f x, you get back g. But g is not just a piece of code -- g remembers 42 somehow :) Closures are required to implement lexical scoping, and are what makes it possible to remember the environment as in the case above -- that is, to provide first class lexically scoped functions. Actually I think ML and Ocaml have poor design here. Ocaml allows: let x = 1;; let f y = y + x;; So that top level functions (a) may still have an environment such as 'x' above, and (b) f itself is initialised at start up to refer to the environment. It would be more correct IMHO to ban variables from the top level and allow only functions, and, instantiate the functions when they're used. If Ocaml did that, it would ONLY need the code pointer. (Felix has the same problem, but I think of a 'library' statement which bans global scope variables and a 'program' statement which permits them). Note that failure to do (a) also plagues C/C++ and has a high cost -- dynamic linkage of 'static' data is very expensive, nasty, and doesn't really work on most platforms, and, it interferes with re-entrancy, which is the principal requirement for thread safety. This mess because actually .. even in C/C++ functions are closures. -- John Skaller Felix, successor to C++: http://felix.sf.net