Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Ian T Zimmerman <itz@transbay.net>
To: jjgarcia@ind-cr.uclm.es
Cc: caml-list@inria.fr
Subject: Re: Dynamic link libraries
Date: Sun, 3 Jan 1999 15:39:22 -0800	[thread overview]
Message-ID: <199901032339.PAA24463@kronstadt.transbay.net> (raw)
In-Reply-To: <367F6A20.75483E90@ind-cr.uclm.es> (message from Juan Jose Garcia Ripoll on Tue, 22 Dec 1998 10:45:04 +0100)

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




      reply	other threads:[~1999-01-04  7:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-12-22  9:45 Juan Jose Garcia Ripoll
1999-01-03 23:39 ` Ian T Zimmerman [this message]

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=199901032339.PAA24463@kronstadt.transbay.net \
    --to=itz@transbay.net \
    --cc=caml-list@inria.fr \
    --cc=jjgarcia@ind-cr.uclm.es \
    /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