This page describes the CDuce/OCaml interface. This interface allows the programmer to:

• call OCaml functions from a CDuce module;
• export a CDuce model as an OCaml module, by giving it an explicit OCaml signature.

The intended usages for the interface are:

• Piggyback existing OCaml libraries, such as database, network, GUI, data structures;
• Use CDuce as an XML layer (input/output/transformation) for OCaml projects;
• Develop fully mixed OCaml/CDuce projects.

To see how to build CDuce with support for the OCaml interface, see the INSTALL file from the CDuce distribution.

The heart of the interface is a mapping from OCaml types to CDuce types. An OCaml type %%t%% is translated to a CDuce type T(%%t%%), which is meant to be isomorphic to %%t%%: there is a canonical function %%t%% → T(%%t%%) from OCaml values of type %%t%% to CDuce values of type T(%%t%%), and another canonical function T(%%t%%) → %%t%%.

• Basic OCaml types char, int, string, unit are translated respectively to Byte = '\0;'--'\255;', -1073741824 -- 1073741823, Latin1 = [ Byte* ], [] = `nil.
• Tuple types %%t%%1 * ... * %%t%%n are translated to nested CDuce product types (T(%%t%%1),(...,T(%%t%%n))...). A function type %%t%% -> %%s%% is translated to T(%%t%%) -> T(%%s%%). Labels and optional labels on the argument of the arrow are discarded.
• A list type %%t%% list is translated to an homogeneous sequence type [ T(%%t%%)* ]. An array type %%t%% array has the same translation.
• A variant type with a declaration A1 of %%t%%1 | ... | An of %%t%%n is translated to a type (`A1,T(%%t%%1)) | ... | (`An,T(%%t%%n)). If a constructor Ai has no argument, the resulting term is `Ai, not (`Ai,[]). Polymorphic variant types are treated similarly.
• A record type with a declaration { l1 : %%t%%1; ...; ln : %%t%%n } is translated to a closed record type {| l1 = T(%%t%%1); ... ; ln = T(%%t%%n) |}. Mutable fields are just copied.
• Private variant and record types are treated correctly: the interface never tries to generate OCaml values of these types, but it will happily translate them to CDuce values.
• A reference type %%t%% ref is translated to the CDuce reference type ref T(%%t%%). When converting a Caml reference to CDuce, the operation (set,get) on the resulting reference refers to the original reference. However, when converting a CDuce reference to OCaml, the content of the reference is fetched (set), and a fresh OCaml reference is created (copy semantics).
• The type Cduce_lib.Value.t is translated to the CDuce type Any. The corresponding translation functions are the identity. This can be used to avoid multiple copies when translating a complex value back and forth between CDuce and OCaml. The type Cduce_lib.Encodings.Utf8.t is translated to the CDuce type String. The type Big_int.big_int is translated to the CDuce type Int.
• A monomorphic abstract type t is translated to the CDuce type !t. This type just acts as a container for values of the abstract type. CDuce never produces a value of this type, and it cannot inspect the content of such a value (apart from checking its type).

The canonical translation is summarized in the following box:

Only monomorphic types are handled by the interface. It is allowed to use polymorphic constructors as an intermediate, as long as the final type to be translated is monomorphic. Recursive types, including unguarded ones (option -rectypes of the OCaml compiler) are accepted. In the following example:

the type s can be translated, but the type v can't, because its infinite unfolding is not a regular type.

OCaml object types are not supported.

Note that values are copied in depth (until reaching an abstract type, a function types, etc...). In particular, translating an OCaml cyclic values to CDuce will not terminate (well, with a stack overflow!).

If an OCaml value has a type that can be translated, it is possible to use it from CDuce (see the How to compile and link section for more details).

In a CDuce module, you can write M.f to denote the result of translating the OCaml value M.f to CDuce.

If the value you want to use has a polymorphic type, you can make the translation work by explicitly instantiating its type variables with CDuce types. The syntax is M.f with { t1 ... tn } where the ti are CDuce types. The type variables are listed in the order they appear in a left-to-right reading of the OCaml type. Example:

will return a function of type (Int -> String) -> ([Int*] -> [String*])

We have seen in the section above how OCaml values can be used from a CDuce module. It is also possible to use CDuce values from OCaml. To do so, you must give an OCaml interface (.mli) for the CDuce module (.cdo). The interface can define arbitrary types, and declare monomorphic values. These values must be defined in the CDuce module with a compatible type (subtype of the translation).

As an example, suppose you have this CDuce module (foo.cd):

You can define an OCaml interface for it (foo.mli):

When the foo.cdo module is compiled, CDuce will look for the foo.cmi compiled interface (hence, you must first compile it yourself with OCaml), and generate stub code, so as to define an OCaml module Foo with the given interface. This module can then be linked together with other "regular" OCaml modules, and used from them.

Notes:

• It is not mandatory to export all the values of the CDuce module in the OCaml interface.
• The types defined in the interface cannot (currently) be used within the CDuce module.

Here is the protocol to compile a single CDuce module:

• Create a .cmi from your OCaml file with ocamlc -c foo.mli.
• Compile your CDuce file cduce --compile foo.cd. This command will create a CDuce bytecode file foo.cdo, which also contains the OCaml glue code to export CDuce values as OCaml ones, and to bind OCaml values used within the CDuce module.
• Compile the OCaml glue code ocamlfind ocamlc -c -package cduce -pp cdo2ml -impl foo.cdo. Thecdo2ml tool extracts the OCaml glue code from the CDuce bytecode file.

You can then link the resulting OCaml module, maybe with other modules (either regular ones, or wrapping a CDuce module): ocamlfind ocamlc -o {{...}} -package cduce -linkpkg foo.cmo {{...}}. When the program is run, the CDuce bytecode file foo.cdo is looked in the current directory only, and loaded dynamically (with a checksum test).

It might be preferable to include the CDuce bytecode directly into the OCaml glue code. You can do this by giving cdo2ml the -static option: ocamlfind ocamlc -c -package cduce -pp "cdo2ml -static" -impl foo.cdo. Modules which have been compiled this way don't need the corresponding .cdo at runtime.

If you choose static linking, you have to use a correct ordering when linking with OCaml. Note that it is possible to mix static and dynamic linking for various CDuce modules in a same program.

Everything works mutatis mutandis with the native OCaml compiler ocamlopt.

You might need to pass extra -I flags to CDuce so that it could find the referenced .cmi files.

It is possible to run a CDuce module with cduce --run foo.cdo, but only if it doesn't use OCaml values.

Interested users can look at the output of cdo2ml to better understand how the interface works.

The tool cduce_mktop creates custom versions of the CDuce toplevel with built-in support for some OCaml modules / functions.

The first argument is the file name of the resulting toplevel. The second points to a file whose contents specify a set of built-in OCaml values to be embedded in the toplevel. Each line must either be a qualified value (like List.map) or the name of an OCaml unit (like List). Empty lines and lines starting with a sharp character are ignored.

In a custom toplevel, the directive #builtins prints the name of embedded OCaml values.