# Camel Spotting in Paris

*2011-04-15 — note*


I'm at the [2011 OCaml Users Group](https://forge.ocamlcore.org/plugins/mediawiki/wiki/ocaml-meeting/index.php/OCamlMeeting2011) in Paris, reporting on some splendid talks this year. It looked like around 60-70 people in the room, and I had the pleasure of meeting users all the way from [Russia](http://ru.linkedin.com/pub/dmitry-bely/4/955/717) to [New York](http://ashishagarwal.org/about/) as well as all the Europeans\!


### Js\_of\_ocaml

First up was [Pierre Chambart](http://www.lsv.ens-cachan.fr/~chambart/) talking about the [js\_of\_ocaml](http://ocsigen.org/js_of_ocaml/) compiler. It compiles OCaml bytecode directly to Javascript, with few external dependencies. Since the bytecode format changes very rarely, it is simpler to maintain than alternatives (such as Jake Donham’s [ocamljs](https://github.com/jaked/ocamljs)) that require patching the compiler tool-chain. Javascript objects are mapped to dynamic OCaml objects via a light-weight `##` operator, so you can simply write code like:

      class type window = object
          method alert : js_string t -> unit meth
          method name : js_string t prop
        end
        let window : window t =
          JS.Unsafe.variable "window"
        
        let () = 
          window##alert ( window##name)
          name <- Js.string "name"
    

Overloading is handled similarly to [PyObjC](http://pyobjc.sourceforge.net/), with each parameter combination being mapped into a uniquely named function. [Raphael Proust](https://github.com/raphael-proust) then demonstrated a cool game he wrote using via [bindings](https://github.com/raphael-proust/raphael) to the [Raphael](http://raphaeljs.com/) Javascript vector graphics library. Performance of `js_of_ocaml` is good compared to writing it by hand, and they have have quite a few [benchmarks](http://ocsigen.org/js_of_ocaml/doc/1.0.2/manual/performances) on their website.

Overall the project looks very usable: the main omissions are Bigarray, no dynlink, no Str (replaced by native regexps), no recursive modules or weak references. None of these missing features seem very critical for the sorts of applications that `js_of_ocaml` is intended for.

### OCaml on a PIC (OCAPIC)

Next up Phillipe Wang presented something completely different: [running OCaml on tiny 8-bit PIC microcontrollers](http://www.algo-prog.info/ocaml_for_pic/web/index.php)!  These PICs have 4-128Kb of flash (to store the code), and from 256 *bytes* to 4 kilobytes. Not a lot of room to waste there. He demonstrated an example with a game with 24 physical push buttons that beat humans at a conference (JFLA).

It works by translating OCaml bytecode through several stages: `ocamlclean` to eliminate dead code in the bytecode (which would be very useful for native code too!), a compression step that does run-length encoding, and then translation to PIC assembly. They have a replacement stop-and-copy GC (150 lines of assembly) and a full collection cycle runs in less than 1.5ms. Integers are 15-bits (with 1 bit reserved) and the block representation is the same as native OCaml. Very cool project\!

### Frama-C

We went onto static analysis and [Julien Signoles](http://www.linkedin.com/pub/julien-signoles/24/5a9/4b4) presented [Frama-C](http://frama-c.com/), a powerful static analysis tool for real-world C. It forks the [CIL](http://www.eecs.berkeley.edu/~necula/cil/) project from Berkeley and adds [ocamlgraph](http://ocamlgraph.lri.fr/) and GUI support. He demonstrated a simple loop counter plugin to count them in C code, and the homepage has many interesting [plugins](http://frama-c.com/plugins.html) maintained by the community.

I hadn’t realised that CIL was still maintained in the face of [clang](http://clang.llvm.org/), so it’s nice to see it live on as part of Frama-C.

### Ocsigen

The ever-cheerful [Vincent Balat](http://www.pps.jussieu.fr/~balat/) updated us about the [Ocsigen](http://ocsigen.org) web framework, including unveiling their exciting new logo! This was written using an amazing [collaborative editor](http://ocsigen.org/tutorial/tutorial1) that lets users edit in real time.

Ocsigen is based around *services* of type `service: parameters -> page`. Services are first-class values, and can be registered dynamically and associated with sessions. The code for the collaborative editor was about 100 lines of code.

There is a syntax extension to distinguish between client and server side code, and both can be written in the same service (invoking `js_of_ocaml` to compile the client code to Javascript). They have bindings to [Google Closure](http://code.google.com/closure/) in order to provide UI support. There is a really nice “bus” service to pass messages between the server and the client, with seamless integration of [Lwt](http://ocsigen.org/lwt) to hide the details of communication to the browser.

Ocsigen is looking like a very mature project at this point, and I’m very keen to integrate it with [Mirage](http://www.openmirage.org) to specialise the into micro-kernels. A task for the hacking day tomorrow morning I think\!

### Mirage

I talked about [Mirage](http://www.openmirage.org), hurrah! Good questions about why we need a block device (and not just use NFS), and I replied that everything is available as the library and the programmer can choose depending on their needs (the core goal of [exokernels](http://en.wikipedia.org/wiki/Exokernel)).

A highlight for me was lunch where I finally met [Richard Jones](http://people.redhat.com/~rjones/), who is one of the other OCaml and cloud hackers out there. Wide ranging conversation about what the cool stuff going in [KVM](http://www.linux-kvm.org/page/Main_Page) and Red Hat in general. Richard also gave a short talk about how they use OCaml to generate hundreds of thousands of lines of code in [libguestfs](http://libguestfs.org/). There are bindings for pretty much every major language, and it is all generated from an executable specification. He notes that “normal” programmers love the OCaml type safety without explicit annotations, and that it is a really practical language for the working programmer. The [Xen Cloud Platform](http://xen.org) also has a similar [generator](https://github.com/xen-org/xen-api/blob/master/ocaml/idl/datamodel.ml) for XenAPI bindings, so I definitely agree with him about this\!

### OCaml Future

[Xavier “superstar” Leroy](http://pauillac.inria.fr/~xleroy/) then gave an update of OCaml development. Major new features in 3.12.0 are first-class modules, polymorphic recursion, local module opens, and richer operations over module signatures. Version 3.12.1 is coming out soon, with bug fixes (in camlp4 and ocamlbuild mainly), and better performance on x86\_64: turns out a new `mov` instruction change improves floating point performance on `x86_64`.

OCaml 3.13 has no release date, but several exciting features are in the pipeline. Firstly, more lightweight first-class modules by permitting some annotations to be inferred by the context, and it introduces patterns to match and bind first-class module values. Much more exciting is support for GADTs (Generalised Algebraic Data Types). This permits more type constraints to be enforced at compile time:

      type _ t =
          | IntLit : int -> int t
          | Pair : 'a t * 'b t -> ('a * 'b) t
          | App : ('a -> 'b) t * 'a t -> 'b t
          | Abs : ('a -> 'b) -> ('a -> 'b) t
         
        let rec eval : type s . s t -> s = function
          | IntLit x -> x (* s = int here *)
          | Pair (x,y) -> (eval x, eval y) (* s = 'a * 'b here *)
          | App (f,a) -> (eval f) (eval a)
          | Abs f -> f
    

In this example of a typed interpreter, the `eval` function is annotated with a `type s . s t -> s` type that lets each branch of the pattern match have a constrained type for `s` depending on the use. This reminded me of Edwin Brady’s [partial evaluation](http://www.cs.st-andrews.ac.uk/~eb/writings/icfp10.pdf) work using dependent types, but a much more restricted version suitable for OCaml.

There are some really interesting uses for GADTs:

-   Enforcing invariants in data structures, as with the typed interpreter example above.
-   Reflecting types into values means that libraries such as our own [dyntype](http://github.com/mirage/dyntype) can be expressed in the core language without lots of camlp4 hacks. Finally, this should make typed I/O generators for XML, JSON and other network formats much simpler.

The challenges in the implementation are that principle type inference is now impossible (so some annotation is required), and pattern matching warnings are also trickier.

From the IDE perspective, the third bit of work is to have the OCaml compiler save the full abstract syntax tree annotation with source locations, scoping information, types (declared and inferred) and addition user-defined annotations. This generalises the `-annot` flag and can help projects like [OCamlSpotter](http://jun.furuse.info/hacks/ocamlspotter), [OCamlWizard](http://ocamlwizard.lri.fr/), [OcaIDE](http://www.algo-prog.info/ocaide/), etc. It also helps code-generators driven by type-generators (such as our [SQL ORM](http://github.com/mirage/orm) or [ATDgen](http://oss.wink.com/atdgen/)).

The OCaml consortium has new members; [MLState](http://mlstate.com) and [MyLife](http://mylife.com), and [Esterel](http://www.esterel-technologies.com/), [OCamlPro](http://www.ocamlpro.com) and one unnamed new member are joining. The consortium goals are to sell permissive licensing (BSD) to members, and sound off new features with the serious users. Three companies are now doing commercial development (Gerd, OCamlCore, OCamlPro) which is growing the community nicely.

### JoCaml

[Luc Maranget](http://pauillac.inria.fr/~maranget/) (who looks like an archetypal mad professor!) gave a great rundown on [JoCaml](http://jocaml.inria.fr/), a distributed programming extension to OCaml. This extends the compiler with join-definitions (a compiler patch), and a small bit of runtime support (using Thread), and significant extensions for concurrent and distributed programming in a type-safe way.

It extends the syntax with three new keywords: `def`, `spawn` and `reply`, and new usage for `or` and `&` (you should be using `||` and `&&` anyway). Binary libraries remain compatible between matching versions of JoCaml and OCaml. An example of JoCaml code is:

      let create n =
          def st(rem) & tick() = st(rem-1)
          or st(0) & wait() = reply to wait in
          spawn st(n) ; { tick=tick; wait=wait; }
        
        type t = {
          tick: unit Join.chan;
          wait: unit -> unit;
        }
    

After `n` messages to `tick`, the `wait` barrier function will be called.

      let c = create n
        let () =
          for k = 0 to 9 do
           spawn begin printf "%i" k; c.tick ()
          done;
          c.wait ()
    

Here we asynchronously print the numbers of `0` to `9`, and then the `wait` call acts as a barrier until it finishes. JoCaml is useful for distributed fork-join parallelism tasks such as raytracing, but with the type system support of OCaml. It is a bit like MapReduce, but without the data partitioning support of Hadoop (and is more light-weight). It would be quite interesting to combine some of the JoCaml extensions with the dynamic dataflow graphs in our own [CIEL](http://www.cl.cam.ac.uk/research/srg/netos/ciel/) distributed execution engine.

### Forgetful Memoisation in OCaml

[Francois Bobot](http://www.lri.fr/~bobot/) talks about the problem of memoizing values so that they can be re-used (e.g. in a cache). Consider a standard memoiser:

      let memo_f =
          let cache = H.create () in
          fun k ->
            try H.find cache k
            with Not_found ->
              let v = f k in
              H.add cache k v;
              v
        
        let v1 = memo_f k1
        let v2 = memo_f k2 in (* k2 = k1 in O(1) *)
    

If a key is not reachable from anywhere other than the heap, we want to eliminate it from the cache also. The first solution is a normal hashtable, but this results in an obvious memory leak since a key held in the cache marks it as reachable. A better solution is using OCaml [weak pointers](http://caml.inria.fr/pub/docs/manual-ocaml/libref/Weak.html) that permit references to values without holding on to them (see [Weaktbl](http://www.pps.jussieu.fr/~li/software/weaktbl/doc/html/Weaktbl.html) by [Zheng Li](http://www.pps.jussieu.fr/~li/) who is now an OCaml hacker at Citrix). The problem with Weaktbl is that if the value points to the key, forming a cycle which will never be reclaimed.

Francois solves this by using [Ephemerons](http://en.wikipedia.org/wiki/Ephemeron) from Smalltalk.  They use the rule that the value can be reclaimed if the key or the ephemeron itself can be reclaimed by the GC, and have a signature like:

      module Ephemeron : sig type ('a,'b) t
          val create : 'a -> 'b -> ('a,'b) t
          val check : ('a,'b) t -> bool
          val get : ('a,'b) t -> 'b option
          val get_key : ('a,'b) t -> 'a option
        end
    

The implementation in OCaml patches the runtime to use a new tag for ephemerons, and the performance graphs in his [slides](https://forge.ocamlcore.org/docman/view.php/77/134/memoization2011.pdf) look good. This is an interesting topic for me since we need efficient memoisation in Mirage I/O (see the effects on DNS performance in the [Eurosys paper](/papers/2007-eurosys-melange.pdf) which used Weaktbl). When asked if the OCaml patch will be upstreamed, [Damien Doligez](http://gallium.inria.fr/~doligez/) did not like the worst-case complexity of long chains of ephemerons in the GC, and there are several approaches under consideration to alleviate this without too many changes to the runtime, but Francois believes the current complexity is not too bad in practise.

### Oasis and website

[Sylvain](http://sylvain.le-gall.net/) came on stage later to give a demonstration of [OASIS](http://oasis.forge.ocamlcore.org/oasis-db.html), an equivalent of [Cabal](http://www.haskell.org/cabal/) for Haskell or [CPAN](http://www.cpan.org/) for Perl. It works with a small `_oasis` file that describes the project, and then the OASIS tool auto-generates `ocamlbuild` files from it (this reminds me of Perl’s [MakeMaker](http://perldoc.perl.org/ExtUtils/MakeMaker.html)). Once the files are auto-generated, it is self-contained and there is no further dependency on OASIS itself.

- Gallery
  <figure class="image-right"><img src="/images/ocaml-users-1.webp" alt="How many OCaml hackers does it take to change a lightbulb?" title="How many OCaml hackers does it take to change a lightbulb?" loading="lazy" srcset="/images/ocaml-users-1.640.webp 640w, /images/ocaml-users-1.480.webp 480w, /images/ocaml-users-1.320.webp 320w"><figcaption>How many OCaml hackers does it take to change a lightbulb?</figcaption></figure>
  <figure class="image-right"><img src="/images/ocaml-users-3.webp" alt="Wearing bibs at French Teppinyaki" title="Wearing bibs at French Teppinyaki" loading="lazy" srcset="/images/ocaml-users-3.640.webp 640w, /images/ocaml-users-3.480.webp 480w, /images/ocaml-users-3.320.webp 320w"><figcaption>Wearing bibs at French Teppinyaki</figcaption></figure>
  <figure class="image-right"><img src="/images/ocaml-users-2.webp" alt="Team Mirage cheeses it up" title="Team Mirage cheeses it up" loading="lazy" srcset="/images/ocaml-users-2.640.webp 640w, /images/ocaml-users-2.480.webp 480w, /images/ocaml-users-2.320.webp 320w"><figcaption>Team Mirage cheeses it up</figcaption></figure>

OASIS works with either an existing build system in a project, or can be integrated more closely with `ocamlbuild` by advanced users. Lots of projects are already using OASIS (from Cryptokit to Lwt to the huge [Jane Street Core](http://caml.inria.fr/cgi-bin/hump.en.cgi?contrib=641)). He is also working on a distribution mechanism on a central website, which should make for convenient OCaml packaging when it is finished and gets more adoption from the community.

Finally, [Ashish Agarwal](http://ashishagarwal.org/) led a discussion on how OCaml can improve its web presence for beginners. Lots of good ideas here (some of which we implemented when reworking the [CUFP](http://cufp.org) website last year). Looking forward to seeing what happens next year in this space! I really enjoyed the day; the quality of talks was very high, and many engaging discussions from all involved\!

<figure class="image-center"><img src="/images/sf-ocaml.webp" alt="" title="" loading="lazy" srcset="/images/sf-ocaml.640.webp 640w, /images/sf-ocaml.480.webp 480w, /images/sf-ocaml.320.webp 320w"><figcaption></figcaption></figure>

Of course, not all of the OCaml community action is in France. The ever-social [Jake Donham](http://www.twitter.com/jakedonham) organised the First Ever San Francisco User Group that I attended when I was over there a few weeks ago. Ok, admittedly it was mainly French people there too, but it was excellent to meet up with [Mika](http://www.linkedin.com/pub/mika-illouz/0/a02/7b4), [Martin](http://martin.jambon.free.fr/), [Julien](http://www.linkedin.com/pub/julien-verlaguet/20/10a/b57), [Henri](http://fr.linkedin.com/in/henribinsztok) and of course Jake when over there.

We should definitely have more of these fun local meetups, and a number of other OCaml hackers I mentioned it to want to attend next time in the Bay Area, if only to cry into their drinks about the state of multi-core... *just kidding*, [OCamlPro](http://www.ocamlpro.com) is hard at work fixing that after all :-)

Synopsis: Report from the 2011 OCaml Users Meeting in Paris, covering talks on js_of_ocaml, OCaml on PIC, and more.
Words: 2278
DOI: 10.59350/zb6ye-yfk38

## Related

- [OCaml Labs](https://anil.recoil.org/projects/ocamllabs) (project, 2012-01-01)
- [OCaml Meeting 2011 - MirageOS](https://anil.recoil.org/videos/7d949597-b864-4ada-ab1a-81ff8c0463e2) (video, 2011-10-19)
  The OCaml Meeting 2011 talk on MirageOS in France, with full notes in :ocaml-users-group

---
Canonical: https://anil.recoil.org/notes/ocaml-users-group
Type: note
License: CC BY 4.0 <https://creativecommons.org/licenses/by/4.0/>
Tags: ocamllabs