Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
ocaml for embedding
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-07-09 (10:29)
From: Gaspard Bucher <gaspard@t...>
Subject: Re: [Caml-list] ocaml for embedding
Hi David !

Thanks for the pointer. From my understanding of the use of
caml_startup (or caml_main), this means that the caml runtime is
global. In Rubyk, each "object" (processing unit) is separated from
all other objects (no globals) so that we can properly encapsulate
operations without side effects and provide fine grained locking
(concurrency is important).

Is there a way to avoid:

1. global locking (or locking only during script recompilation)
2. script level encapsulation

Point (2) would mean that if object "a" contains the script:

 let foo a, b = ... do something

and object "b" contains:

 let foo x, y = ... do something else

The recompilation of script "b" does not change the definition of
function "foo".

One possible solution would be to force the creation of singleton
classes for each script named after the script name (unique):

let script_a = object
  method foo a, b = ...

let script_b =
  method foo x, y = ... do something else (does not hide script_a::foo)

This would solve the encapsulation problem, but what about concurrent
calls to ocaml from C ? Is this possible ?


On Fri, Jul 9, 2010 at 9:06 AM, David MENTRE <> wrote:
> Hello,
> 2010/7/8 Gaspard Bucher <>:
> > 1. Is it possible to embed an ocaml compiler ? (something that eats
> > std::string and produces a callable thing)
> No, not the compiler. It is however possible to embed an interpreter
> and to load byte code (and native code?) on demand:
> > 2. How would an interface between C++ and a compiled script work ? (passing
> > values, getting return values)
> Through a C interface. See above link.
> Sincerely yours,
> david