Previous week Up Next week


Here is the latest Caml Weekly News, for the week of June 12 to 19, 2007.

  1. DSL for handling parsing binary memory structures?
  2. OCaml software developer position at INRIA
  3. Intended behavior of GenerateMap
  4. JOB: OCaml job in static analysis, Newport Wales
  5. New release GLCaml
  6. Dynamic linking
  7. OCaml + GTK vs F# on Windows
  8. Ocamlodbc 2.14
  9. Ledit 3.10
  10. Smoke Vector Graphics 2.01
  11. New York Functional Programmers Meetup
  12. camlp5?

DSL for handling parsing binary memory structures?


Richard Jones asked and answered:
> I wonder if anyone has thought about or developed a domain-specific 
> language in OCaml for handling the processing of binary structures? 

> I was thinking of writing something to make system calls into the Xen 
> hypervisor.  The main problem is that the hypervisor takes & returns 
> binary structures which have very precise size / alignment 
> requirements, bitfields, etc. (and the requirements change with 
> versions of the hypervisor).  It sounds like the ideal use for a DSL 
> to describe the binary structure of each version of each call and 
> automatically build accessors. 

I had a play with some code to do this.  A write-up of my experiment 
is here:

OCaml software developer position at INRIA


Christophe Gensoul announced:
We are currently offering a software developper position for a young 
engineer with good programming skills wanting to work in our research 
team AOSTE at INRIA-Rocquencourt. SynDEx is written in OCaml and is 
quite a big software (around 50,000 lines). You can get details about 
this position on our website: Click on the jobs link in 
the menu on the left. 

Please send your curriculum and motivation letter to

Intended behavior of GenerateMap


Nicolas Pouillard said:
I've added to  the Camlp4 wiki a documentation about 
Camlp4MapGenerator and Camlp4FoldGenerator

JOB: OCaml job in static analysis, Newport Wales


Richard Jones announced:
I'm just passing this one along.  If interested, contact me and I'll 
put you in touch. 
I gather that it requires relocation to Newport in Wales.

New release GLCaml


Elliott Oti announced:
GLCaml (, a dynamic cross-platform Ocaml 
binding for OpenGL and extensions,  has been updated to version 
20070616. It contains the following changes: 
* Almost all current OpenGL extensions are now supported, doubling the 
previous number of supported extensions. 

* GLCaml should now compile on generic unix, and now works on Solaris. 
as well as Windows, Linux, and Mac OSX. 

* It has been re-released under the BSD license. It was previously 
released under the LGPL. 

* SDLCaml has a few minor bugfixes incorporated. It remains under the 

Dynamic linking


Alain Frisch announced:
I'm pleased to announce the existence of an experimental branch in 
OCaml's CVS. Main changes: 

* Dynamic loading of OCaml code in native code programs, through 
  the Dynlink module. 

* Simplified dynamic linking of C code under Windows. 

More info: 

Enjoy and send some feedback!
Brian Hurt asked and Alain Frisch answered:
> B) How extensive were the changes to the Ocaml source code? 

For Linux x86, the change is rather small and straightforward. 
For Windows ports, it is more tricky, because a Windows DLL cannot 
reference symbols from the main program. I wrote the FlexDLL tool to 
simulate a POSIX-ish dlopen API, so that the patch to OCaml itself 
mostly reduces to removing code or sharing Makefiles with Unix. All the 
trouble is encapsulated into FlexDLL (which is itself a quite small 
piece of code, but a tricky one). 

>From Linux AMD64, the ABI/dynamic linker does not allow to dynamically 

load position dependant code, so I had to modify the last stage of 
ocamlopt's backend in order to produce PIC code (when the option -dlcode 
is given; note that this is independant from the existing -fpic option, 
details on demand). Again, this is a rather small and unintrusive change. 
You can use CVS to get a diff between the ocaml3100 tag and the 
natdynlink branch (but it won't show you new files; you can always "cvs 
checkout" both and do a local diff). 

> How likely 
> is it that this will get included in some future version of the main trunk? 

It is likely to be included in OCaml 3.11, not before. (Except for the 
native toplevel which will probably not be included.) Of course, 
feedback can only help for the integration.
Jon Harrop asked and Alain Frisch answered:
> Is that "native" as in we're going to get an OCaml top-level with native-code 
> performance? If so, this is hugely important for me... 

What kind of application do you have in mind? 
It's "native" as in "we have an OCaml top-level with native-code 
performance and a large latency". Each phrase is compiled with 
ocamlopt's backend to an assembler file, which is then assembled, linked 
into a shared library, dl-opened and then run. (Shared libraries will 
never be closed so your OS must be strong enough to support that.) 
Performances will likely be equal to ocamlopt's generated code (in 
particular, we have cross-phrase optimizations). 

Feel free to play with it ("make ocamlnat") and tell us whether this is 
adequate for what you want to do.
Jon Harrop later said:
The native top-level is the bit that interests me the most, as this combines 
interactivity with OCaml's superb native-code performance. 
I just benchmarked the new top-level and it runs my ray tracer 17x faster: 

$ time ocaml unix.cma >image.pgm 

real    1m11.656s 
user    2m21.106s 
sys     0m0.331s 

$ time ocamlnat unix.cmxa >image.pgm 

real    0m4.294s 
user    0m6.265s 
sys     0m0.521s 

Interactive compilation to native code was one of the main benefits of F# over 
OCaml. So I, for one, would dearly love to see this in the mainstream OCaml!
Quôc Peyrot asked and Alain Frisch answered:
> Is it working (or going to work) on PPC (Mac OS X)? 

It is not currently working. The code generator must be adapted to 
produce PIC code. I've started to do that but it doesn't work and I 
won't be able to finish it. If someone is interested to help, please 
tell me.

OCaml + GTK vs F# on Windows


Joel Reymont asked and Richard Jones answered:
> I need to reboot my translator as a Windows app. I would like to know   
> how well is LablGTK supported on Windows (specially with Glade) and   
> whether this is advisable if Windows is my only target platform. 

Have a look at:

Ocamlodbc 2.14


Christophe TROESTLER announced:
It is my pleasure to announce the availability of Ocamlodbc version 2.14. 

Ocamlodbc is an wrapper for various ODBC drivers (mysql, postgresql, 
unixodbc, oracle, SQLserver,...). 

This release features a better compilation and installation script 
under windows (incorporating suggestions from Dmitry Bely) and a 
slightly improved documentation.  It has been tested to work under 
windows server 2003 and SQLserver.

Ledit 3.10


Ralph Douglass asked and Daniel de Rauglaudre answered:
> Is there a copy of ledit floating around that compiles under 3.10?  The 
> latest version I found was 1.13, at  I 
> may just not know where to look. 

Ledit compiles perfectly with Camlp4s that you can download on my site. 
I am sorry, I am not going to port my softwares (GeneWeb, ledit, 
mlrogue, olibrt) into the new Camlp4, because I don't agree with the 
fundamental choices of that camlp4 (in particular, changes in the 
syntax tree, and I disagree the use of some libraries, programs, 
programming and compilation technics, interfaces, tools, source 

These choices are too different to be compatible with my point of 
view. I would like to cooperate with the OCaml team to improve their 
Camlp4, they are nice people but they are taking to what I call 
wrong directions. (They know my point of view, I told them.) 

I need Camlp4 for GeneWeb, but I did not manage to port it to the new 
Camlp4, and it is the main reason why I resurected the version of 
Camlp4 I had. These days, I have been preparing a new version with a 
new pretty printing system used and documentation pages. 

If it is a question of naming, I can rename my Camlp4 into Camlp5 or 
whatever, but ledit will not be translated into the Camlp4 distributed 
with OCaml.
Jon Harrop also suggested:
You just need to translate the sources into vanilla OCaml using OCaml 3.09 and 
camlp4 and then it is forwards compatible: 
$ mkdir trans 
$ camlp4o -I ext pa_s.cmo pr_dump.cmo pr_o.cmo >trans/ 
$ camlp4o -I ext pa_s.cmo pr_dump.cmo pr_o.cmo >trans/ 
$ camlp4o -I ext pa_s.cmo pr_dump.cmo pr_o.cmo >trans/ 

Then you can compile the new sources (in ./trans) with OCaml 3.10: 

$ cd trans 
$ ocamlopt unix.cmxa -o ledit 

Hey presto, new ledit binary. Ah, the beauty of camlp4. :-)

Smoke Vector Graphics 2.01


Jon Harrop announced:
We just released a new version of Smoke, including a free byte-code edition: 

Smoke is a high-performance cross-platform 2D vector graphics library written 
entirely in OCaml that renders using OpenGL to exploit hardware acceleration. 
Version 2.01 adds: 

* Compilation for OCaml 3.10.0 
* Vector text using the Computer Modern fonts (see 

We are working towards typesetting, GUIs and a vector graphics replacement for 
the OCaml top-level...

New York Functional Programmers Meetup


Brian Hurt announced:
I'd like to announe the New York Functional Programmers Meetup, which is 
Wednesday, June 27th, 7PM, at the offices of Jane Street Capital. 

The NYFP meetup is for people using or interested in strongly typed 
functional languages, such as Ocaml, Haskell, SML, etc. 

Meeting details are here: 

(sorry about the Lisp category- it's the closest thing Meetup has to 
"Functional Programmers").



John Skaller said:
Hi, I thought I'd briefly report progress on a subsystem of Felix 
which may prove a useful technology for Ocaml. 
I am using Dypgen 

and Ocs scheme 

together for building Felix AST terms in a flexible way. 

Dypgen is an *extensible* GLR parser generator which is now working 
reasonably well. Syntactic forms in the input language can be parsed 
so that the user actions extend the grammar being parsed, including 
adding new non-terminals and handling conflicts. GLR parsers can 
parse any context free language, and work with many grammars for 
such languages, and although some care is required obtaining reasonable 
performance, an Ocamlyacc-like (LALR1) grammar seems to parse about 
the same speed as Ocamlyacc. 

The big problem with extensions is not the grammar, but the user 
actions. To solve this problem, I have chosen to use Scheme programs 
as user actions. Ocs_scheme is written in Ocaml and is very easy 
to work with, and appears quite fast. 

With this combination, user action codes are written as 'text' 
which is then compiled and executed to produce an Ocs_types.sval 
or scheme value. These values are basically s-expressions. 

Felix converts them to a simple s-expression format, then 
converts them to Felix AST_format with a laboriously coded 
mapping. Of course the typing is dynamic, up to the building 
of the AST. The AST built is the same one the same Ocamlyacc 
grammar would have yielded. 

At this point I am moving 95% of the Felix grammar into 
a user library, so that the 'initial' hard coded grammar 
is 'more or less' reduced to: 

(a) the top level compilation unit (start symbol) 
(b) some code for parsing syntax extension syntax 
(c) an effective top level dummy non-terminal 
(d) a set of bottom non-terminals which wrap tokens with attributes, 
   such as literals and names 

The bits 'in between' are all programmed in the input source, 
that is, user written library code. 

The same idea could be used for Ocaml. Instead of using ocamlp4 
to separately build extensions, the extensions are defined 
directly in the source code that needs them, and ocaml 
parses it. Note: dypgen syntax extensions are properly scoped. 

Felix uses the format: 

syntax schemer { 
  s_term := sprefixed =># "_1"; 
  s_term := s_term / spower =># "`(ast_apply (div (,_1 ,_3)))"; 
  s_term := s_term % spower =># "`(ast_apply (mod (,_1 ,_3)))"; 


open syntax schemer; 
so that the grammar definitions are defined separately from 
use. At the moment Felix #includes this input into the program 
that needs it, however the layout is design to support separate 
compilation of the grammar definitions, so that only the 
'open syntax' is required. That statement provides the linkage 
to the language sorely missing from the current ocamlp4 engineering. 

However the above system is much more flexible because it is 
properly scoped -- the opened syntax is only accessible in 
the scope an Ocaml 'open' would normally make names available. 

Thus, you could easily define 'macros' to help implement 
modules without impacting other modules, even in the same 
translation unit. 

Whilst Scheme isn't the best language for processing Ocaml AST terms 
or extensions to them, it has the advantage of being a complete, 
well known, high power symbol processing languages. To use the system 
you only need to learn a bit of Scheme plus your base AST mapping. 

The technology appears different from MetaOcaml because the 
staging is localised, that is, the phasing is recursed bottom up 
not top down (but I may be wrong on that!) as well as using 
a distinct meta-language which is of course unpleasant, particularly 
the dynamic typing. 

When Ocaml 3.11 is released I hope to extend the technology to 
also support dynamic loading of semantic extensions. It's probable 
these extensions will be plugged directly into Ocs_scheme as 
primitives, so that the Ocaml based AST is discarded permanently. 
[The whole compiler will become a Scheme program, albiet with 
very specialised primitives written in Ocaml] 

Most term rewriting systems are 'effectively' dynamically typed, 
even if they use some lower level static typing as support. 
Rewrite rules have both pre- and post- conditions which can't 
be represented with static typing, and excess static typing 
appears to seriously impeded modification of the term rewriting 
systems. These systems are 'interpreting' terms no matter 
what -- that is, they're intrinsically dynamically typed. 

Using s-expressions is a rather extreme encoding, and is 
basically TOO dynamic IMHO, but it does seem to represent 
a good compromise when there is an emphasis on extension 
and experiment. The point is that whilst a more static 
encoding is safer for simpler extensions .. it really 
gets in the way badly when the extension is a complex 
function of an already complex term encoding. 

It would be interesting if someone wanted to use this idea 
to make a new camlp5 front end to Ocaml.

Using folding to read the cwn in vim 6+

Here is a quick trick to help you read this CWN if you are viewing it using vim (version 6 or greater).

:set foldmethod=expr
:set foldexpr=getline(v:lnum)=~'^=\\{78}$'?'<1':1

If you know of a better way, please let me know.

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