caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: skaller@users.sourceforge.net
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Delaying module initialization
Date: Mon, 29 Mar 2004 12:36:54 +0900	[thread overview]
Message-ID: <20040329123654I.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: <1080517867.4708.174.camel@pelican.wigram>

From: 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()?

You are mixing here different problems, and I can interpret your
question in several ways.

If your question is: can I load simultaneously several shared
libraries containing some C functions with the same name, then the
answer is probably: only under windows. But I did not try, so maybe it
works on other systems too, or maybe it doesn't work on windows for
some reason.  This is a question of C binary namespace, flat or
hierarchical.  To simplify writing libraries, ocaml uses the flat
model (more usual on Unix), but windows happens to support only the
hierarchical model.

If it is: can I choose at runtime which shared library to load, and
provide a unified interface independent of the library, then the
answer is yes. IIRC, CamlGL uses that to allow choosing your openGL
library at runtime. There are some pitfalls, like the fact you need to
provide a different stub library (both C and caml part) for each
shared library you want to load, or the fact you cannot unload a
library. But in my opinion the main problem is that different
libraries shall probably have different signatures under the refined
ocaml type system, so that it will be very hard to use a unified
interface (we have already trouble with the different version of Gtk+-2.x).

If it is: can I dynamically generate stubs for a shared library,
compile them (both C and caml part) and load the library in the same
program, then this should be yes too.  Automatizing all this might be
a lot of work, but there is no theoretical limitation.  Again there
may be problems with name spaces, but if this is really your concern
you just have to change one line in ocamlrun sources to use the
hierarchical model.

> If dynamic loading is as Jacques suggests, then it would
> seem mod_caml has a strange design..
> 
> Given an HTML page containing some Caml script
> which in invokes some functions which wrap
> Perl modules .. the whole thing should be 
> dynamic automatically.
> 
> I can't see how 'initialising all the Perl modules'
> could happen. I'd have to try extremely hard to even
> think about how to make that happen.

Here we enter another problem: ocaml has dynamic loading, but not
auto-loading/initializing.  Looks like lots of people would want to
have that: a module would be initialized only when one of its members
is used. This is _not_ a problem of dynamic loading, and this could
actually change the semantics of the language, since initializing one
module might force initializing another one in its turn, and as a result
module initialization might not be sequential.  On the other hand, this
should not be too hard to do with bytecode, at least java style: parse
the .cma's, but do not load their dependencies immediately.

Without auto-loading, you end-up loading everything in your name
space; so that would result in initializing all Perl modules if you
are initializing them on load. Some workarounds have already been
suggested to delay this initialization.

Jacques Garrigue

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


  reply	other threads:[~2004-03-29  3:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-26 16:59 Richard Jones
2004-03-26 17:26 ` Yamagata Yoriyuki
2004-03-26 18:44   ` Richard Jones
2004-03-26 19:05     ` Remi Vanicat
2004-03-27 10:19       ` Richard Jones
2004-03-27 11:18         ` Xavier Leroy
2004-03-27 11:21           ` Richard Jones
2004-03-27 15:47             ` skaller
2004-03-27 12:38           ` Benjamin Geer
2004-03-27 16:04             ` skaller
2004-03-28 10:34               ` Jacques Garrigue
2004-03-28 23:51                 ` skaller
2004-03-28 23:58                 ` skaller
2004-03-29  0:35                   ` skaller
2004-03-29  3:36                     ` Jacques Garrigue [this message]
2004-03-29  6:10                       ` skaller
2004-03-27 15:41           ` skaller
2004-03-26 21:10 ` skaller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040329123654I.garrigue@kurims.kyoto-u.ac.jp \
    --to=garrigue@kurims.kyoto-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=skaller@users.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).