Previous week Up Next week


Here is the latest Caml Weekly News, for the week of 28 December 2004 to 04 January 2005.

Happy New Year to everyone.

  1. Anyone tried to compile Ocaml on .NET?
  2. Parser for configuration file
  3. recmod
  4. OCaml NAE releases Cf-0.5 and Iom-0.1
  5. Internships and Post-doctoral Positions at MSR Cambridge
  6. MacOS port and file formats
  7. Ocaml in String Theory
  8. timer

Anyone tried to compile Ocaml on .NET?


SooHyoung Oh asked:
Is there anyone who has ever tried to compile ocaml on .NET environment?

I can find lots of infomation from the ocaml-mailing list:

Mono project:
John Goerzen's message:

After some test on F#, my feeling is that it's not so good as Ocaml.
So I'm looking for Ocaml implementation on .NET environment.
(Interoperability is not my concern.)

There is a message that because the type system of Ocaml is so complex
that it's not easy to make But I think it's not so difficult
to compile Ocaml on .NET, is it?
Tom Hirschowitz suggested:
What about this work by Raphael Montelatici and others?
Richard Jones also answered:
One possibility is running .NET code on the Mono VM, embedded in an
OCaml process.  It seems like it should be possible, although the
specifics of how the two garbage collectors might behave together is

Parser for configuration file


Romildo asked and Jørgen Hermanrud Fjeld suggested:
> Is there a library that implements a parser
> for configuration files similar to the *.ini
> files from windows? For instance:
>   [section 1]
>   key1 = value1
>   key2 = value2
>   [section 2]
>   key3 = value3
>   key4 = value4
>   key5 = value5

May I suggest ConfigParser from missinglib:



Anastasia Gornostaeva asked and John Skaller answered:
> Is it possible to compile such files?
> let get a =
>    if Mod2.mem a then 1 else 2
> let mem a = List.mem a [1;2;3]
> let other () =
>    print_int (Mod1.get 5)

No. There is a new experimental feature which provides
some support for intra-module recursion,
but at present the modules must reside
in the same file.

The two common workaround for functions are:

(a) pass Mod2.get to Mod1.get as an argument

(b) create a reference in initialised to 
   fun (x:int) -> raise Not_found; 1

   and in store Mod2.get into it, call it in
   by first dereferencing it.

Another technique is to use classes, which automate
the late binding more safely.

OCaml NAE releases Cf-0.5 and Iom-0.1


James Woodyatt announced:
Today, the OCaml Network Application Environment (NAE) has released 
maintenance updates of two of its published libraries.  As its project 
page on SourceForge.Net says, OCaml NAE is "a collection of Objective 
Caml libraries to support the development of concurrent, 
single-threaded Internet application servers."

For downloads and more information, please see:

The two libraries updated in this release are the Core Foundation (Cf) 
and the Reactive I/O Monad (Iom).  The Cf library was formerly known as 
the Pagoda Core Foundation.  The complete CHANGES records for both 
libraries since their previous releases follows below.

===== OCaml NAE Core Foundation (cf) library =====
===== Version 0.5 =====

Highlights of the changes:

+ Many bugs fixed (some critical).
+ IPv6 socket addresses are now a triple, containing the scope 
+ Fixed a very bad stack leak problem in the [Cf_gadget] scheduler.

--- [Cf_deque]
     Fix major bug in [fold] that caused a BUS ERROR (ack!), and also fixed 
     [filter] so that it uses the non-recursive [fold] function here instead of 
     going to the extra work of using [Cf_seq.fold].

--- [Cf_rbtree]
     Fix a bug in [iterate] (found by Craig Falls; thanks Craig!) caused by a 
     stoopid typo.  Caused some elements to be iterated twice, and others not 
     at all.

--- [Cf_gadget]
     Moderate surgery on the scheduler to fix a bad stack leak.  The new code 
     is probably a tiny bit more efficient too, because I got rid of some
     unnecessary uses of {Lazy.t} in places, and there is a bit less lifting
     between monads.  I didn't benchmark it, though.

--- [Cf_socket]
     Added a special case for Mac OS X to work around a bug in Apple's network 
     stack that errors in connect(2) on a non-blocking socket do not get in the 
     errno system variable.  You have to get them out of the socket with the 
     SO_ERROR socket option.

--- [Cf_ip4_addr]
     Make the network subnet manipulation functions cope with networks that are 
     not unicast networks.  (Yes, there are multicast ranges that can be 
     treated like subnets.)

--- [Cf_ip6_proto]
     Add a third element to the socket address type: an int32 for the scope id.

--- [Cf_ip6_addr]
     Fix the [v4compat] and [v4mapped] address type tags so that they are 
     actually polymorphic variants, like they're supposed to be.  This was 
     another stoopid typo, but I found it myself.

--- [Cf_netif]
     Fixed the C-language code to call if_nametoindex() with the proper 
     arguments.  Again, this was a stoopid typo.

--- [Cf_poll]
     A minor change to the commented bits of debugging code in the middle of 
     the select loop to use [Cf_journal] instead of my [xprintf] hackery.

--- {TESTS}
     Added a test for the [Cf_gadget] scheduler to detect stack leaks.

===== OCaml NAE Reactive I/O Monad (iom) library =====
===== Version 0.1 =====

Highlights of this release:

+ Rewrote the [Iom_sock_stream.endpoint] reactor to fix bugs (and 
hopefully improve performance in some edge cases).
+ More optional tests coded (but they're still suboptimal, and maybe 

--- [Iom_sock_stream]
     Rewrote the [endpoint] reactor to use less consing, i.e. the state is now 
     a couple of mutable objects derived from [Cf_poll.event].  Events are 
     plumbed around the inside of the reactor in shorter paths.

--- [T_iom]
     Change to be compatible with cf-0.5 notion of IPv6 socket addresses, which 
     now contain an int32 element for the scope identifier.

--- {New Tests}
     Added a couple of new programs which help me work out bugs.  I don't think 
     these programs are really done, since they don't quite give me the control 
     I need to be able to adequately test and benchmark the performance of code 
     based on the [Iom] library.  I'll probably need to hammer on these for a 
     while before I have something to document.  In the meantime, consider them 
     curiosities for your amusement.

Internships and Post-doctoral Positions at MSR Cambridge


Don Syme announced:
On behalf of those at Microsoft Research, Cambridge, I would like to announce 
that applications for intern positions at our lab for 2005 are now being 
accepted.  Our lab has a number of groups, but of particular interest may be 
the Distributed Systems group (, the 
Programming Principles and Tools group ( and 
the Security group (  For myself I am 
particularly interested in applications for projects related to type systems, 
virtual machines and/or aspects of language design and implementation related 
to .NET, ML and F# (  Specific 
interests of other researchers are detailed on their home pages, and in general 
you should consider discussing potential projects with a specific researcher 
soon after applying.

Cambridge is a great place to work, and Internships normally last 12 weeks and 
most commonly occur over the summer. Applicants should be graduate students on 
PhD programs.

For summer 2005 Internships, the deadline for complete applications is 28th 
February 2005, and references have to be received by this date. The admission 
process is quite competitive, and we encourage applications in good time before 
the deadline. We aim to notify candidates of the outcome of their applications 
by the end of April 2005.

Full details and application forms can be found at the following link:

In addition, we are always open to applications for a smaller number of 
post-doctoral positions.  Full details can be found at

MacOS port and file formats


Mary Fernandez asked and Jacques Garrigue answered:
> I have a question regarding the ./configure options for MacOS/Darwin.
> ./configure selects the -bundle option for MKSHAREDLIB, which
> has the effect of creating MacOS bundle type files for the dynamically
> linked libraries in lib/ocaml/stublibs.  I have had trouble linking
> these bundle files with the standard dynamically linked libraries
> created with the -dynamiclib option.    As an experiment, I replaced
> -bundle by -dynamiclib and attempted to rebuild the O'Caml compiler,
> but got an error deep in compilation of the compiler.  Ultimately,
> I just made the otherlibs/* libraries by hand with -dynamiclib and was
> able to link my application.
> I will admit that I am overwhelmed by the Darwin documentation
> that explains how to port a Linux application to MacOS. 
> Can someone explain why the -bundle option is necessary to the compiler
> compilation?
> Is it because the O'Caml compiler a full-fledged Mac application?

Could you explain exactly what you are trying to do?
The dlls in stublibs are only intended to be dynamically loaded by an
ocaml application. The reason bundles are used rather than dynamic
libraries is that the API for bundles is simpler, and that their
explicit intent (plugins) seems close enough to the use of dlls in
Note that a bundle can depend on dynamic libraries, so this should not
induce other limitations.
Mary Fernandez replied:
Thanks for your message.  Here is what I am trying to do.

My O'Caml application is an XQuery engine.  It has three
APIs: one for O'Caml, one for C, and one for Java applications.

We create a native-code, dynamically linked
C library that includes our O'Caml library, the O'Caml runtime,
and several other C libraries that our application depends upon
the unix, nums, str libraries plus an external PCRE library.
We actually do this by hand with ocamlopt (not ocamlmklib)
because in the past, we found ocamlmklib did not work consistently
on all platforms.

What I have found is that if the dll*.so libraries are Mac bundle
files, then I get a linking error of the form 
"...ld: /Users/mff/ocaml-3.08.2/lib/ocaml/stublibs/libstr.dylib is input
for the dynamic link editor, is not relocatable by the static link
editor again..."
(Note that the default name of is not recognized by the 
Darwin linker).  If I re-compile the otherlibs/ in stublibs/
to be dynamically linked libraries, then I have no problems.
Also, if I just use the archive files, that works too -- but
I typically use O'Caml with dynamic libs enabled which is how
I tripped over this problem.

We only create a dynamically linked library, because 
our Java library call the C library, and the Java JNI requires
dynamically linked C libraries.

So, in short, I have something that works, but still dont'
understand why bundles and dynamically linked libraries caused
me trouble.
Jacques Garrigue answered:
> My O'Caml application is an XQuery engine.  It has three
> APIs: one for O'Caml, one for C, and one for Java applications.
> We create a native-code, dynamically linked
> C library that includes our O'Caml library, the O'Caml runtime,
> and several other C libraries that our application depends upon
> the unix, nums, str libraries plus an external PCRE library.
> We actually do this by hand with ocamlopt (not ocamlmklib)
> because in the past, we found ocamlmklib did not work consistently
> on all platforms.

To be more precise, ocamlmklib produces two kinds of output: a DLL for
dynamic loading in bytecode programs, and a static library for custom
and native programs.
What you seem to want is a dynamic library to link with native
programs, which is out of the specification.

On most architectures, the DLL can be used as a dynamic library, but
this is not true on darwin, and only partly true on windows (you also
need a binding library, which is not kept.)

If your concern is darwin, then there is a simple answer: you can just
get the installed static library, and turn it into a dynamic library,
as all C code on darwin is position independent. Just look for the
correct linker incantation in the darwin manual.
It's better not to try to meddle with the core ocaml compilation,
which has different goals in mind.
Jacques Garrigue then added:
In case you could not find it, here is the incantation:

  ld -dylib -all_load -flat_namespace -undefined suppress 
    /usr/local/lib/ocaml/libunix.a -ldylib1.o -o libunix.dylib

You can also link all these libraries directly in your dynamic linked
C library, without creating individual dlls (but this works only for
platforms such as darwin, where all code is position independent).

Ocaml in String Theory


Thomas Fischbacher announced:
Ladies and Gentlemen,

a happy new year to all readers of this list.

For a non-mainstream language like Ocaml, it is evidently of great 
importance to have good answers to the question about its practical 
relevance. It seems as if we now have another nice application to add to 
the list: in today's official listing, the following 
preprint paper (by myself and two colleagues from the Albert Einstein 
Institute) appeared:

Physically speaking, one of the hot topics in string theory today is the 
conjectured equivalence of certain quantum field theories which neither at 
the classical level nor as quantum theories have an intrinsic length scale
on the one side - so-called conformal field theories - and string theory 
on a space-time which approaches constant negative curvature at infinity 
(i.e. anti deSitter space) - see e.g.

What we did was to provide further strong evidence that the physical key 
property of integrability holds, however another important property known 
as BMN scaling (sorry, I cannot go into details) is violated in 
quite non-obvious ways.

Computationally, what we had to do in order to achieve this result was to 
develop a fast algorithm which furthermore can be implemented close to the 
machine level that allows us to sum literally billions of contributions 
from different planar feynman graphs with four loops in them. Planarity is 
the key property here that makes this calculation feasible - if we 
included the non-planar graphs as well, we would have had to deal with an 
estimated number of contributions of about half a quadrillion.

At the much simpler three loop level, our approach is faster than 
previous ones (using the FORM program which was built explicitly for fast 
quantum field theoretic calculations) by about a factor of 100. This comes 
in part from our improved algorithm that singles out planar graphs (and 
hence scales much better than algorithms which do not), in part from 
doing term transformations not in an interpreted fashion, but 
directly at machine code level (via compiled ocaml), furthermore from 
carefully ensuring not to do unnecessary work when simplifying terms,
from evil hacks (such as abusing the FPU to do exact(!) fraction 
arithmetics for fractions of the form <small numerator>/<small power of 2>),
and - quite important - from certain algorithmic tricks from the 
functional programmer's toolbox such as continuation coding and lazy 
evaluation. In other words, it would not at all have been possible
in anything else but a fast compiled functional language. Nevertheless, 
we still had to burn 88 000+ CPU-hours on 2 GHz Athlon (and Opteron) 
hardware to do the largest piece of the calculation and we are very 
grateful towards our numerical colleagues for providing us with 
appropriate resources - this is true symbolic supercomputing.

While we (the authors) are not yet sure about this, we think to have 
strong reason to believe that this may be the (presumably by orders of 
magnitude) largest symbolic algebra calculation performed so far - 
counting the number of term transformations. (Excluding cypher breaking 
and prime search attempts, as the underlying questions hardly can be 
regarded as of symbolic nature.) We know that there have been quite large 
four-loop QCD calculations before involving something like 50 000 
individual graphs that furthermore had to deal with some transformations 
on integrals (which we do not have, due to a certain kind of reduction we 
perform in our model) and hence are somewhat more difficult to calculate 
than our graphs - but certainly not by a factor of 100 000. If anyone 
knows better and can tell us about an even larger symbolic calculation, we 
would be glad to hear about it.

While our paper is essentially for physicists, it features a 
self-contained appendix explaining the algorithmic and implementation
aspects of our work that should be readable especially for people with a 
computer science background. Furthermore, one can download (details in the 
paper) our source. Unfortunately, in order to actually build the program, 
one needs a somewhat large development environment, as some of the ocaml 
source and data files are machine generated by perl and CMU Common Lisp. 
Admittedly, the code could be cleaner, but one should keep in mind here 
a few external factors (i.e. pressure to publish new physical 
results) which are different for computer scientists and physicists. 
Well, it's not as bad as quite a lot of code in physics, and I 
think I can show it around without having to pull a brown paper bag over 
my head, but the style is certainly not one I'd like to see in textbooks.
Given the time (which I at present do not have), I'd like to clean it up 
a bit more.



Anastasia Gornostaeva asked and SooHyoung Oh answered:
> Does exist Timer module, that allows me add/reset/remove timed events?
> Currently I use Unix.setitimer() for my simple implementation that allows
> only adding new events into a queue, but my skills is not enough to implement
> reset and remove events from the Timer queue.
> And I'm not sure if using Unix.sleep() with setitimer() is safely (without
> Threads).

I have one at .

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}$'?'&lt;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