Dynamic link libraries

Dynamic link libraries

[Juan Jose Garcia Ripoll]

Hi everyone,

let me introduce myself. I'm a newcomer to ML and to the world of
functional programming in general. I'm currently giving OCaml and
Moscow-ML a try. From OCaml I like the possibility of writing external C
functions, but I dislike the limits that it imposes, that is:

* One has to generate a custom runtime

* One has to link those libraries against the runtime.

I believe this breaks modularity. Isn't it possible to support the
following?

* Creation of *shared* bytecode/native-code Caml libraries.

* Dynamic loading of those libraries, much like Moscow-ML does: a simple
'load "filename.uo"'. (Moscow-ML is based on Caml-Light -- thus I
believe this must be possible, somehow)

* Linked executables (either native/bytecode ones) that make use of
those libraries.

* Dynamick linking of native DLLs, that is, those which are generated by
the C compiler, such as libX11.so, etc. This is just a matter of 30
lines code in Linux and other unices which support the `dlopen'
function.

* Exposure of the symbols loaded from a DLL, so that they are recognized
in "external" clauses.

This would lead to a better development evironment, and to some space
saving due to not having to produce custom runtimes. I will appreciate
any comment about why this hasn't been done already.

Regards

	Juanjo

P.S: I don't know French, hence this single version message.

Re: Dynamic link libraries

[Ian T Zimmerman]

> Date: Tue, 22 Dec 1998 10:45:04 +0100
> From: Juan Jose Garcia Ripoll <jjgarcia@ind-cr.uclm.es>
> X-UIDL: e6222666435699efcb7296793c186224
> 
> Hi everyone,
>  let me introduce myself. I'm a newcomer to ML and to the world of
> functional programming in general. I'm currently giving OCaml and
> Moscow-ML a try. From OCaml I like the possibility of writing
> external C functions, but I dislike the limits that it imposes, that
> is:
>  * One has to generate a custom runtime
>  * One has to link those libraries against the runtime.
>  I believe this breaks modularity. Isn't it possible to support the
> following?
>  * Creation of *shared* bytecode/native-code Caml libraries.
>  * Dynamic loading of those libraries, much like Moscow-ML does: a
> simple 'load "filename.uo"'. (Moscow-ML is based on Caml-Light --
> thus I believe this must be possible, somehow)
>  * Linked executables (either native/bytecode ones) that make use of
> those libraries.
>  * Dynamick linking of native DLLs, that is, those which are
> generated by the C compiler, such as libX11.so, etc. This is just a
> matter of 30 lines code in Linux and other unices which support the
> `dlopen' function.
>  * Exposure of the symbols loaded from a DLL, so that they are
> recognized in "external" clauses.
>  This would lead to a better development evironment, and to some
> space saving due to not having to produce custom runtimes. I will
> appreciate any comment about why this hasn't been done already.

For bytecode, what you are looking for already exists; see the Dynlink
library.

I'd think type checking (or lack of it) is the biggest obstacle
against doing the same for native code.

But if you're mostly worried about wasting store by replication of the
same native code in multiple runtimes/executables, you can always use
a shared library for your worker routines and use a C style dynamic
loader such as dld from your stubs.

Or am I missing something?

-- 
Ian T Zimmerman                        <itz@transbay.net>
I came to the conclusion that what was wrong about the guillotine
was that the condemned man had no chance at all, absolutely none.
Albert Camus, _The Outsider_