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
CamlIDL - stub code generator and COM binding for OCaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 1999-03-08 (07:49)
From: Andrew Martin <amartin@i...>
Subject: Re: CamlIDL - stub code generator and COM binding for OCaml
This looks great!.

I have been thinking of writing an interface between Ocaml and the GTK.  This
tool should simplify the task considerably.

I have one concern about the handling of structs. Actually, it's more of a
concern with Ocaml than with idl, but idl makes the problem more apparent.

How can one deal with two struct types whose members have the same names.
In Ocaml, for example:

type foo = {a:int; b:int}
type goo ={a:char; b:char}

How can I now create an object of type foo?  It would be nice if I could write
let x = ({a=4; b=5;}:foo) or
let x = {foo.a=4; foo.b=4} or even
let (x:foo) = {a=4; b=4}

The problem isn't too bad if one is writing native caml code, since one takes
care to avoid re-using field names.  I typically write something like:

module Foo = struct type t = {a:int; b:int} end
module Goo = struct type t = {a:char; b:char} end

However, if one is defining a caml interface for existing C code, the problem is
much worse, since the C code will have been written without regard for the need
to avoid reusing the same field name in different struct types.

Xavier Leroy wrote:

> Just like everyone else who has read the papers on H/Direct by Meijer,
> Peyton-Jones et al, I have been working lately on a COM binding for
> Objective Caml.  I have just released one of the preliminary results
> of this work: CamlIDL 1.00.  Sources and documentation are available from
> The documentation can also be browsed at
> CamlIDL comprises two parts:
> - A stub code generator that generates the C stub code required for
>   the Caml/C interface, based on an MIDL specification.  (MIDL stands
>   for Microsoft's Interface Description Language; it looks like
>   C header files with some extra annotations, plus a notion of object
>   interfaces that look like C++ classes without inheritance.)
> - A (currently small) library of functions and tools to import COM
>   components in Caml applications, and export Caml code as COM
>   components.
> CamlIDL can be used in several ways:
> - Under Unix and Windows, as a stub code generator for using C
>   libraries from Caml.  It takes care of the gory details of
>   the Caml/C interface, such as all those pesky Val_xxx and Xxx_val
>   macros, proper registration of GC roots, the different calling
>   conventions from bytecode and from native-code, etc.
> - Under Unix and Windows, as a simple interface between Caml classes
>   and C++ classes.  The C++ fragment supported is that corresponding
>   to COM interfaces, i.e. interface polymorphism, but not inheritance.
>   Communication in both directions (COM/C++ object to Caml object
>   and Caml object to COM/C++ object) is provided.
> - Under Windows, as a COM binding for Caml.  There are two applications:
>   * Use COM components from Caml applications.  This should eventually
>     allow Caml code to exploit many Windows libraries and "script"
>     many Windows applications.  See the H/Direct papers for nice
>     examples.  This hasn't been tried yet with CamlIDL, because of
>     the incredible lack of documentation on Microsoft's components
>     and on Microsoft's IDL extensions they use in their interfaces.
>   * Encapsulate Caml code in COM components that can be used in
>     other applications.  This offers great potential for writing
>     the juicy bits of an application in OCaml and use C++ or Visual
>     Basic or Internet Explorer or whichever Microsoft behemoth to do
>     the GUI and other boring parts.  Currently, CamlIDL can create
>     "in-proc servers" for Caml components (i.e. DLLs that are registered
>     in the system registry and loaded automatically in applications
>     that use the components).  "Out-of-proc" servers and distributed
>     objects are not supported yet.  Currently, only native interfaces
>     are supported, but not yet dispatch interfaces.
> While the stub generation aspects of CamlIDL are already relatively
> mature, the COM binding is still very preliminary.  My hope in
> releasing it is that others more experienced with COM than I am will
> try it on real-world applications and let me know what is wrong or
> missing.
> - Xavier Leroy

Andrew K. Martin, Ph.D.
Motorola Inc., Somerset Design Center
Networking and Computer Systems Group

phone: (512) 424-8325        6200 Bridgepoint Parkway, Building 4,
fax  : (512) 424-8846        Mail Drop OE70
email:    Austin, TX 78730