From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.6.10/8.6.6) id SAA04458 for caml-redistribution; Thu, 28 Dec 1995 18:46:33 +0100
Received: (from xleroy@localhost) by pauillac.inria.fr (8.6.10/8.6.6) id RAA03255; Thu, 28 Dec 1995 17:13:29 +0100
From: Xavier Leroy <xleroy@pauillac.inria.fr>
Message-Id: <199512281613.RAA03255@pauillac.inria.fr>
Subject: Re: Dynamic linking in CSL?
To: carroll@louie.udel.edu (Mark C. Chu-Carroll)
Date: Thu, 28 Dec 1995 17:13:29 +0100 (MET)
Cc: caml-list@pauillac.inria.fr
In-Reply-To:  <9512221909.aa01551@auriga.cis.udel.edu> from "Mark C. Chu-Carroll" at Dec 22, 95 02:09:29 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: weis


> Is it possible, in CSL, to dynamically load and link a CSL module
> which matches a static signature?

Yes. The current distribution of Caml Special Light includes a dynamic
linking library (in otherlibs/dynlink), originally developed for
implementing applets in the MMM browser, but general enough (I think)
for your needs.

There is some documentation in otherlibs/dynlink/dynlink.mli. I'll try
to summarize the main points below.

First of all, the library provides no mechanism for accessing values
defined by a dynamically-linked module. (That would be hard to do in a
type-safe way.) So, the dynamically-linked module must register
explicitly the functions it exports with the application, e.g. by
storing these functions in mutable data structures. For instance:

        let f x = ...
        let g y = ...
        let _ =
          App.extension_functions :=
            ["f", f; "g", g] @ !App1.extension_functions

Here, "App" is assumed to be a module from the application, that defines

        let extension_functions = ref ([] : (string * (int -> int)) list)

Calling an extension function given its name is a simple "assoc" in
that list.

For this reason, the signature of the dynamically-linked module does
not matter. What matters, for type safety, is the signatures of the
modules from the application that the dynamically-linked module references.
The dynlink library checks that the dynamically-linked module has been
compiled against the same interfaces for these application modules as
the application modules themselves. This ensures type safety.

Say your application is composed of three modules, App App2 App3.
You would initialize the dynamic linker as follows:

        Dynlink.init();
        Dynlink.add_interfaces
          ["Pervasives";"Array";"String";"Char";"App";"App2";"App3"]
          ["/the/sources/of/my/application";
           "/usr/local/lib/caml-special-light"]

The add_interfaces function sets the list of modules that
dynamically-linked code can reference. Here, we allow access to the
three application modules, plus a number of standard library modules.
The second argument is a list of directories where the .cmi files (the
compiled signatures) for these modules are found.

Then, linking a file foo.cmo is as easy as

        Dynlink.loadfile "foo.cmo"

There are some extra features in the library, but I hope you get the
general idea. Write caml-light@pauillac.inria.fr for more info.

Regards,

- Xavier Leroy