From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id BCA77BB81 for ; Wed, 10 Nov 2004 00:57:35 +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 iA9NvZWs025035 for ; Wed, 10 Nov 2004 00:57:35 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA02176 for ; Wed, 10 Nov 2004 00:57:34 +0100 (MET) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id iA9NvWRn025022 for ; Wed, 10 Nov 2004 00:57:33 +0100 Received: from [192.168.1.200] (ppp217-99.lns1.syd3.internode.on.net [203.122.217.99]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id iA9NvQ4Y082431; Wed, 10 Nov 2004 10:27:26 +1030 (CST) Subject: Re: [Caml-list] Native Module Linking From: skaller Reply-To: skaller@users.sourceforge.net To: Nicolas Cannasse Cc: caml-list In-Reply-To: <000e01c4c6a6$fcbca9f0$19b0e152@warp> References: <00bc01c4c68b$4f1f6d70$19b0e152@warp> <1100036274.6138.10.camel@pelican.wigram> <000e01c4c6a6$fcbca9f0$19b0e152@warp> Content-Type: text/plain Message-Id: <1100044645.6138.114.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 10 Nov 2004 10:57:26 +1100 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 4191596F.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 4191596C.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 sourceforge:01 cannasse:01 wrote:01 bug:01 ocamlc:01 bug:01 ocaml:01 modname:01 rec:01 modname:01 semantics:01 module's:01 dynlink:01 rec:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: On Wed, 2004-11-10 at 08:56, Nicolas Cannasse wrote: > It depends exactly on what information basis linking is done OK: open isn't relevant to static linking :) I think its a hack, and probably a bug, that ocamlc works differently -- same for win32. However I think the bug is actually in the Ocaml language itself: there's no way to properly control order of initialisation. I would suggest: import Modname import rec Modname open Modname (* implies import *) Semantics: (1) any side effects of Modname's initialisation code shall occur prior execution of the client module's initialisation code. (2) If Dynlink is imported, then exposing the symbols of a module to a Dynlinked module is considered a side-effect. (3) The order of initialisation for import rec is unspecified, however if a module is imported (without rec) and it is mutually recursive with another, both these modules will be initialised before the client's initialisation. The effect of 'import' is principally to guarrantee side effects won't be dropped, just because a module happens to be otherwise unused. In particular, these semantics are made part of the language, rather than dependent on how the program is linked, and whether it happens to be bytecode or not... With one CAVEAT: it isn't specified how the root or root modules are determined. In C, the root is the function main(). In Ocaml, the roots would be any modules listed on the linker command line. Note that the guarrantee doesn't release the programmer from the requirement to specify compilation and linkage order, instead it just forces the actual ordering constraints to be manifest in the language. Apart from increasing slightly the determinism of Ocaml code, this extension would significantly simplify dependency analysis tools like Ocamldep. [in fact you could probably use a 3 line shell script instead .. :] Any comments appreciated but be warned of the possible biases of ex-Pythonistas :) And yes I know this would break a lot of code, which I think is good. Obviously, the feature should be introduced with a switch to enable it, then the default should be changed so you have a switch to support legacy code. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net