Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Delaying module initialization
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-03-28 (23:51)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] Delaying module initialization
On Sun, 2004-03-28 at 20:34, Jacques Garrigue wrote:

> > The former is interesting but not industrially satisfying
> > because it doesn't allow dynamic loading of interfaces
> > to C, which must be native code.
> But, this is plain wrong: since 3.04 you can dynamically load C stubs
> through dynamically loading a bytecode library.

This I do not understanding but I seem to have missed something. 

Are you saying I can write a module which wraps a C library 
with function f(), and another which wraps a different 
function f() of another  shared library, and then write a 
program which can be run like:

loadit X
loadit Y

where the first script invokes X's f() and the second Y's f()?

That wasn't my understanding, but that is exactly what Python
and Perl can do, and it's what is required. If you can do this
you have a clumbsy way of generating code at run time and
executing it, which is a fairly minimal condition
for an extensible program. Interscript, for example, requires
this facility (it uses the Python exec feature to do it
one way, and importing of generated files as another).

Another example which is less abstract: dynamically choose
which version of GTK to run, meaning both the C shared library
used *and* the wrapper code used are chosen at run time.

John Skaller,
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: