Re: [Caml-list] Native Module Linking

[skaller <skaller@users.sourceforge.net>]

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