Previous week Up Next week


Here is the latest OCaml Weekly News, for the week of June 23 to 30, 2015.

  1. Sequoia: MySQL query builder via syntax tree manipulation
  2. Post-doctoral position available at ENSTA-ParisTech - Secure-OCaml project
  3. OCaml embedded
  4. ocaml-4.02.2 for iOS
  5. Next OUPS meetup, 9th of July 2015
  6. POSIX message queue implementation
  7. Other OCaml News

Sequoia: MySQL query builder via syntax tree manipulation


Andre Nathan announced:
So this was mostly an experiment for me to learn how to work with PPX
extensions. It's a hack that I'm sure will affect people's sensibilities
about what should be done with PPX, though maybe someone will find it
useful. It's far from complete so I didn't bother creating an OPAM
package yet.

The idea is to have a safe query builder for MySQL. You map a database
using an OCaml module like so:

module MyDB = struct
  type my_table = {
     id   : int    [@sql];
     name : string [@sql];
  } [@@sql]
end [@@sql]

The @sql/@@sql attributes can take an extra string that will map to the
real MySQL column/table/database names in case they differ from their
OCaml names.

With that definition you can then build a query:

let%sql query =
    MyDB.my_table as_ t

Which will build the query below via `Sequoia.Select.to_string query`:

  SELECT `t`.`name` FROM `MyDB`.`my_table` AS `t`

Variable substitution is supported using the ref syntax:

let pat = Sequoia.string "a%"
let%sql query =
    MyDB.my_table as_ t
    ( like !pat && > 1)

If you reference a database, table or column that isn't declared via the
@sql/@@sql attributes or call a nonexistent MySQL function, you get a
compile-time error:

let%sql query =
    MyDB.my_table as_ t

  => This expression has type [> `Frob of [> `Column of string list ] ]
     but an expression was expected of type Sequoia.Function.t
     The second variant type does not allow tag(s) `Frob

If you try to select a column from a table that's not in a from or join
clause, you get an error too:

let%sql query = select

  => Table `my_table` not selected in query

There are many problems though. Off the top of my head:

* Everything must be lowercase;
* Error reporting sucks;
* You need parentheses around OCaml expressions that wouldn't be needed
  in real SQL;
* Lots of MySQL functions are not defined yet so you'll get bogus
* Due to syntax clash you need stuff like "as_" or "in_";
* Need to find a way to make it work when the DB definitions are in
  separate files;
* Conversion to string doesn't indent the query and is really
* Everybody hates MySQL.

Post-doctoral position available at ENSTA-ParisTech - Secure-OCaml project


Michel Mauny announced:
We have a post-doctoral position available at ENSTA-ParisTech (Palaiseau,
France), to be filled as soon as possible, on the Secure-OCaml project. See
below for more information.

 * Secure-OCaml - Checking safety and security properties of OCaml programs

 * English (Voir plus bas pour une version française.)

Offer: postdoc
Publication date: June 23 2015
Workplace: ENSTA-ParisTech, Palaiseau
Duration: from 12 to 24 months
Starting: ASAP
Salary: from 2200 € to 2400 € net per month (incl. social security)

Mission: design and implement libraries for verifying safety and security
properties of dynamically loaded OCaml code and data.

Description: The Secure-OCaml project aims at adapting the OCaml language to
the development of applications involving security issues. The project gathers
the following industrial and academic partners: OCamlPro, SafeRiver, LexiFi,
TrustInSoft, INRIA, ENSTA-ParisTech, CEA, and Trusted Labs.

Among the objectives of the Secure-OCaml project, the safety of dynamically
loaded code and data is a particularly important issue. In the same way as
static typing ensures safety properties about statically linked code,
applications shoould be able to have similar ensurance about dynamically
loaded code and data.
The postdoc's mission will be to study these problems and bring effective
solutions that shall be made freely available to the OCaml community.

This work will be realized in cooperation with INRIA-Paris and OCamlpro SAS.

Profile sought:

  - skills in typing and compilation
  - strong capabilities and taste in functional programming in general and
    OCaml in particular
  - a knowledge of the OCaml compiler is an additional advantage

Context of the job: ENSTA-ParisTech is a french (top ten) engineering schools,
located at Palaiseau, on a campus shared with INRIA and Ecole Polytechnique.
The research group "Software Safety and Reliability of Software" is part of
ENSTA's Computer Science and System Engineering Department, and aims at
improving techniques of development, analysis and verification of software.

For more information, contact:

  - michel.mauny <at> ensta-paristech <dot> fr
  - +33 1 8187 2032

To apply, send the following documents to michel.mauny <at> ensta-paristech
<dot> fr:

  - your resume, with a list of publications
  - a motivation letter
  - the name and address (e-mail) of two persons who could write
    a recommendation

Applications will be received as long as the position remains available. Please check at:

that the position is still available.

OCaml embedded


Xavier Deschuyteneer asked:
I would like to develop in ocaml for ARM based embedded systems running custom
Linux (build with yocto).

My main questions are how to achieve this:
- cross compilation (ARM/x86)
- stack size control/analysis (valgrind massif tools for ocaml?)

Do you have some pointers? experience?
Markus Weißmann replied and Berke Durak added:
> I can offer experience in the following cases:
> 1) If your system is powerful enough (e.g. rasperry pi), you can just
> install the ocaml toolchain on your system and develop there on your target
> system.

Seconded.  We did almost that for one of our projects and it works
pretty well.  The difference is that we didn't use QEmu, but two of
our custom Q7 board (based on a Zynq ARM Cortex A9 with 512 MB RAM,
see ).

We use Yocto to generate two versions of a Linux system: the target
system, and a much larger version that contains developer tools (C
compiler, m4, etc.)  The development system runs from microSD cards,
and takes the better part of a gigabyte, while the target system has
to run from < 64 megs of flash.  The required run-time dependencies of
the target system have to be manually configured in the Yocto recipes.

We then manually install opam on the developer board, and use it to
compile our OCaml code. The generated native ARM executables are then
packaged into .ipks and transferred to the target Q7 board (connected
to actual hardware: )
The packaging is done using a simple shell script that invokes ar and

We did try using QEmu but it's significantly slower, however it may
come into play as automating the build process (using a virtual
machine or dedicated hardware) is on our to do list, and build time
isn't as important when it's a nightly automated build.

Initially we looked into using a cross-compiler but we decided that
being able to use Opam largely outweighs any possible benefit we could
get from cross-compiling.  And cross-compiling is often a source of
headaches, even when compiling plain old C.  We would have to write a
lot of Yocto recipes to get it running.  Note that Yocto is written in
a progarmming language called Python and requires recipes to be
expressed mostly the same language.

To conclude, as powerful ARM systems are very cheap and plentiful
these days, and since the convenience of Opam is immense, I'm not sure
there is much incentive in using a cross-compiler.  BTW, is there a
maintained ARM cross-compiler?

> 2) Another possibility would be to use qemu (scratchbox, deboostrap, ..) to
> run a complete ARM-linux-root on your x64/x86 linux system via chroot.
> I especially like the 2nd one, as you can use your powerful development CPU
> but your software and toolchain behave nearly perfectly like you are on your
> target system.
Francois Berenger replied:
> Initially we looked into using a cross-compiler but we decided that
> being able to use Opam largely outweighs any possible benefit we could
> get from cross-compiling.

If the feature request for opam called opam-mkbundle


is implemented some day, this would allow people to
ship ocaml software as source code without requiring
end users to install opam.
Gerd Stolpmann also replied:
> To conclude, as powerful ARM systems are very cheap and plentiful
> these days, and since the convenience of Opam is immense, I'm not sure
> there is much incentive in using a cross-compiler. 

There is when you develop for a closed system like iOS.

Also, there is now arm64, and so far I know there are no boards yet.

>  BTW, is there a maintained ARM cross-compiler?

It's in mainline, 4.02.2. It's still a little bit difficult to use,
because IMHO some convenience targets are missing in the Makefile.
Whitequark in his Android packages just generates a configuration and
avoids the problems (see,
it is in particular essential to set CAMLRUN to the host compiler's ocamlrun).
For the iOS branch (not yet in mainline) we added cross-all and cross-opt
targets to the Makefile (see This might be
easier to start with (this branch contains the changes required for the iOS
assembler, but should also work for a GNU toolchain). See the script
in this repo for an example how to configure and build.
Xavier Deschuyteneer said and Pierre-Alexandre Voye replied:
> When i say embedded system, i really mean embedded system running on a
> minimal Linux with low power CPU, not so much flash, same for the RAM.
> It's similar to think that a raspberry pi is a IOT. It's not, it's mini
> computer on ARM platform. In my case, it's really an embedded system, low
> cpu, not so much ram, neither flash.
> And btw i know exactly how yocto works because i build myself our OS. And
> that's not exactly python, it's a mix between python and bash.
> We build two different distributions: one ARM and one x86 (for emulation
> purpose, valgrind, etc.). and all tools(chains) associated.
> This ocaml software needs to be integrated in this workflow.
> Right now, we use plain C, and yes cross compilation is a specific setup,
> but it's not difficult to achieve.
> The advantage right now to use cross compilation are:
> We can use all the power of a real computer to build/debug/code.
> I can use all the interfaces that my computer have and not my end
> (embedded) system: multiple ethernet cards, bluetooth, usb, etc.
> I have multiple projects to manage and all of them are not embedded
> related.
> Thanks for your answer and the time spent for my question :-)
> TL;DR: i need to cross compile ocaml code to arm because my device is not
> powerful enough and that's not possible in industrial purpose to change
> that.

So, maybe you could have a look on two differents projects :

- Ocapic (1)
- Ocamlcc (2)

Ocapic (1) provide a caml virtual machine for a PIC, and tools to minimise
code size.
Ocamlcc (2) is a tool to generate plain C code from ocaml bytecode. There's
risks that the code could be two large, but it can work.

Of course, these way are slower because of bytecode.

ocaml-4.02.2 for iOS


Gerd Stolpmann announced:
I rebased our development branch to 4.02.2, and did few quick tests, and
everything seems to work. At this point I'd like to invite all iOS
developers to check out our work, and help us finding the last bugs:

What you get is a cross compiler for either armv7, armv7s, or arm64. See
the instructions below how to install.

This branch is based on Jeffrey Scofield's work to port ocaml to (32
bit) iOS. We (Gerd, Jeffrey and Mark) added support for armv7s and
arm64, and tried to better adapt to the coding standards of the ocaml
sources. There is an effort to merge this branch into mainline OCaml.

So how to install:

 - You need a host ocaml compiler for Mac, and this compiler must also
   be version 4.02.2, and the word size must match the word size of the
   target (i.e. 64 bit for arm64, and 32 bit for armv7/armv7s). Please
   take these requirements seriously - they are checked. The
   host compiler must be in your PATH.
 - Clone:
   git clone
 - Look at the checked-out script. Modify the variables for
   platform, target, and SDK version.
 - Configure and build: ./ -prefix /where/you/want/it
 - Install: make install

What you get:

 - The installed compilers remain dependent on the host installation
   (so don't delete it after building). In particular, the "ocamlrun"
   executable of the host is still used.
 - The installed runtime is for the target, in particular all the
   libraries (such as libocamlrun.a, and libasmrun.a)
 - The native-code compiler ocamlopt generates executables, but you
   can also emit object files (-output-obj) that can be linked with
   any existing app. You'll also need libasmrun.a in this case.
 - For completeness, you can also use ocamlc -custom to generate
   stand-alone bytecode executables. I guess this is less interesting,
   and I'm not sure whether Apple would allow this format in the app

Next OUPS meetup, 9th of July 2015


Thomas Braibant announced:
The next OUPS meetup will take place on the 9th of July, at
IRILL. We will have a few talks, followed by pizzas.

The program of the talks is:

- David Maison. Experience report: developing an heavy GUI in a lightweight
client with js_of_ocaml
- Fabrice Le Fessant. ocp-lldb: a new debugger for OCaml
- Jeremy Yallop. Experiences with MetaOCaml in the classroom
- Mathieu Boespflug. Cloud Haskell

To register, or for more information, go here
(Registration is recommended, so that we can order enough food.)

Thomas, for the organizers of the meetup

POSIX message queue implementation


Markus Weißmann announced:
are there any libraries that implement/interface POSIX message queues?
(mq_open(3), mq_close(3), mq_send(3), ..)
I only found one [1] -- for which there is neither an opam nor debian package
(probably because of it's potpourri style).
And if there is no "standard" library, what would be the best library to push
an implementation upstream to? (extunix, standard-lib, ..)


Gabriel Scherer then suggested:
Extunix would be a reasonable choice (I also thought of Ocamlnet). I
would encourage you, however, to release a mq-specific library if you
can (possibly depending on one of those libs for helper functions; you
don't necessarily need to be self-contained). Many users are wary of
large monolithic libraries, and being a library of its own will allow
the features to be easier to search for in, say, the package manager.

Other OCaml News

From the ocamlcore planet blog:
Thanks to Alp Mestan, we now include in the OCaml Weekly News the links to the
recent posts from the ocamlcore planet blog at

Cumulative moving average:

Old cwn

If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.

If you also wish to receive it every week by mail, you may subscribe online.

Alan Schmitt