Section: New Results
The Objective Caml system, tools, and extensions
The Objective Caml system
This year, we released version 3.10.0 of the Objective Caml system. This version, distributed in may 2007, is a major release featuring in particular:
A major overhaul of the Camlp4 preprocessor and pretty-printer, re-structured in a more modular and extensible manner. (See section 6.5.3 .)
A new development tool: the OCamlBuild compilation manager. (See section 6.5.4 .)
The introduction of virtual instance variables in classes. Like methods, these instance variables can be re-defined in sub-classes.
The extension of the stack backtrace mechanism (printing context for uncaught exceptions) to native-code programs.
Two new ports to the AMD/Intel 64-bit architecture running Windows 64, and to the PowerPC 64-bit architecture running MacOS X.
A bug-fix release, version 3.10.1, is in preparation and should be distributed in january 2008. Xavier Leroy and Damien Doligez acted as release manager for 3.10.0 and 3.10.1, respectively.
CaFL: ReFLect over OCaml
Nicolas Pouillard, in collaboration with Damien Doligez and Michel Mauny, develops a new implementation of a functional programming language called reFLect. Used at Intel Corporation to perform model-checking and verification of circuits, reFLect supports both lazy evaluation and imperative features and uses binary decision diagrams as a generalization of boolean values. The language also includes an advanced overloading system and reflective aspects. This work, supported by a contract between INRIA and Intel, started in September 2005.
The first year of the project has been devoted to produce a specification of the language and a prototype of compiler for the core language, called CaFL. Nicolas Pouillard carried on Virgile Prevosto's work from July 2006 and continued the development of CaFL compiler and language features. Michel Mauny and Nicolas Pouillard designed the CaFL overloading system and resolution mechanism, along the lines of reFLect and Nicolas Pouillard integrated it into the CaFL compiler.
Nicolas Pouillard then integrated a reflection mechanism that allows to write programs manipulating other programs. This fairly advanced feature is used by Intel to build a theorem prover on top of it and use a “proof by evaluation” technique.
Nicolas Pouillard also designed and implemented other CaFL features such as active patterns, type abbreviations, syntactic macros and improvements to the OCaml debugger.
The Camlp4 pre-processor
Participant : Nicolas Pouillard.
Camlp4 is a source pre-processor for Objective Caml that enables programmers to define extensions to the Caml syntax (such as syntax macros and embedded languages), redefine the Caml syntax, pretty-print Caml programs, and program recursive-descent, dynamically-extensible parsers. For instance, the syntax of OCaml streams and recursive descent parsers is defined as a Camlp4 syntax extension. Camlp4 communicates with the OCaml compilers via pre-parsed abstract syntax trees. Originally developed by Daniel de Rauglaudre, Camlp4 has been maintained since 2003 by Michel Mauny, and is now developed by Nicolas Pouillard.
Starting during his internship in 2006, Nicolas Pouillard designed and implemented a new, modular architecture for the Camlp4 subsystem, aiming at facilitating its maintenance as well as simplifying the implementation of extensions. This reimplementation was finished this year, and released as part of OCaml 3.10.0. Nicolas Pouillard continues to maintain the new Camlp4 and provides support to developers of Camlp4 syntax extensions, helping them to transition to the new version.
The OCamlBuild compilation manager
The OCamlBuild compilation manager was added to the OCaml distribution in the 3.10.0 release. OCamlBuild automates the recompilation and dependency analysis for OCaml projects. It implements the so-called “cut-off” strategy, reducing the amount of recompilation performed. For simple projects, OCamlBuild's built-in compilation rules entirely automate the build process: no “Makefile” is needed. Variations on the built-in rules can be specified compactly through a “tag” mechanism. For more advanced projects, OCamlBuild can be extended through plug-ins written in OCaml itself.
OCamlBuild has been initially developed by Nicolas Pouillard and Berke Durak in collaboration with Alain Frisch. Nicolas Pouillard continues to maintain it.
Dynamic linking of native code for Objective Caml
Participant : Alain Frisch.
Modern applications are often structured around a kernel which can be dynamically extended with plugins. Since its first version, Objective Caml has come with a Dynlink module that supports this kind of decomposition. It allows Caml modules to be loaded in a running Caml program, without compromising static type-safety guarantees. The Camlp4 preprocessor, for instance, relies on this module to dynamically load syntax extensions and pretty printers.
The Dynlink module, however, has been available only for the bytecode compiler. This year, Alain Frisch extended the Dynlink mechanism to work with the native-code optimizing compiler as well. The high-level design of the Dynlink native module – which includes coherence checks between the plugin and the main application – is very close to the bytecode one, and the Caml interface is in fact strictly the same. Some care had to be taken to ensure that internals structures related to the garbage collector and other aspects of the runtime system were properly handled.
Internally, the native Dynlink module relies on the underlying operating system's support for dynamic libraries. Some operating systems were easy to deal with because their dynamic libraries support naturally the Dynlink model: plugins can freely refer to symbols defined in the main program or in previously loaded plugins. Other operating systems required more work. For instance, the Linux AMD64 port required some tweaks in the back end of the Objective Caml compiler so as to produce position-independent code.
More difficult was the work needed to make the native Dynlink module available for the three Windows ports (Microsoft, Cygwin and MinGW toolchains). The problem is that Windows DLLs cannot refer to symbols provided in the surrounding dynamic environment; instead, they must statically refer to specific import libraries so as to resolve at link-time all the external symbol references. After a first working implementation that required heavy surgery on the back end of the Objective Caml compiler, Alain Frisch decided to adopt another strategy and we wrote a tool, called FlexDLL, which emulates the classical POSIX dlopen API on top of Windows DLLs. FlexDLL works as a wrapper around the underlying linker that turns unresolved symbol references into data in order to postpone their resolution until run-time.