English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

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 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