Re: [Caml-list] Delaying module initialization

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

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 X.ml which wraps a C library 
with function f(), and another Y.ml 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, 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



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners