Browse thread
Native Module Linking
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2004-11-09 (23:57) |
From: | skaller <skaller@u...> |
Subject: | Re: [Caml-list] Native Module Linking |
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