Previous week Up Next week


Here is the latest Caml Weekly News, for the week of November 18 to 25, 2008.

  1. Wanted: your feedback on the hierarchy of OCaml Batteries Included
  2. Notes from testing OCaml 3.11.0+beta1 on Fedora
  3. Jobs
  4. Manipulating xml files withing ocaml
  5. Kaputt 1.0 alpha

Wanted: your feedback on the hierarchy of OCaml Batteries Included


David Teller said, spawning a huge thread:
As you know, we've been working for several months of OCaml Batteries
Included. Early in the development, it appeared to us that, with the
large number of modules involved, we would need a hierarchy of modules.

For instance, for the moment, we have a module [System] containing
among other submodules [IO] (definition of i/o operations), [File]
(definition of operations on files), [Sys] (the usual OCaml [Sys]
module, soon to be expanded), etc.  Therefore, before one may open and
manipulate files, one has to do

open System.IO;;
open System.File;;

or, with the syntax extension we developed to alleviate this,

open System, IO, File

The syntax extension does a few other things which we're not going to
detail here -- for one thing, it allows local opening of modules.

Now, we've decided that our current hierarchy is perhaps somewhat clumsy
and that it may benefit from some reworking. Before we proceed, we'd
like some feedback from the community. For this purpose, I have posted a
tree of the current hierarchy on my blog [1]. The documentation is
available online, as usual [2]

Thank you for your feedback,
For the Batteries Pack,

After many messages, David Teller said:
Feedback from active members of the list (and a few other shy people
who seem to prefer answering off-list:)) seems to indicate that
Batteries shouldn't have a general hierarchies of modules but rather a
flat list of modules with a few submodules here and there, along with a
documentation allowing navigation by topics. While that's not my
personal judgement, I'm willing to go along.

So here's a reworked map of the library, along with a few placeholders
to get an idea of where upcoming modules will fit. Text version follows
and html version available on-line:
.. While I personally find this solution a little clumsier than the
previous hierarchy, ymmv. Again, feedback is appreciated.

If anyone is willing to work on a solution for linking documentation
from third-party libraries into one transparent source, as suggested by
Richard Jones, please contact me. I'm sure it is feasible, with a
(un)healthy dose of JavaScript, but I'm not sure that current members of
Batteries have enough brainpower available to work on this on top of


Batteries (pack)
    1. Standard (automatically opened)
    2. Legacy 
            A. Arg
            B. Array
            C. ...
    3. Future (things that should become standard eventually)
            A. Lexers 
                    I. C
                   II. OCaml

       =====  I. Control =====
    4. Exceptions
    5. Return
    6. Monad (Interfaces for monadic operations )
             ==== I.1. Concurrency ====
    7. Concurrency (Interfaces for concurrency operations)
             === I.1.i. Built-in threads ===
    8. Condition
    9. Event
   10. Mutex
   11. RMutex
   12. Thread
   13. Threads (A module containing aliases to Condition, Event...)
             === I.1.ii. coThreads ===
   14. CoCondition
   15. CoEvent
   16. CoMutex
   17. CoRMutex
   18. CoThread
   19. CoThreads (as Threads but with implementations coming from
             === I.1.iii. Shared memory ===
   20. Shm_* (Placeholders)
             ===== II. IO =====
   21. IO 
            A. BigEndian 
   22. Codec (common interfaces for compressors/decompressors)
   23. GZip
   24. Bz2
   25. Zip
   26. Transcode  (Unicode transcoding)
             ===== III. Mutable containers =====
   27. Array 
            A. Cap 
                    I. ExceptionLess
                   II. Labels
            B. ExceptionLess
            a. Labels
   28. Bigarray 
            A. Array1
            B. Array2
            a. Array3
   29. Dllist
   30. Dynarray
   31. Enum 
            A. ExceptionLess
            a. Labels
   32. Global
   33. Hashtbl 
            A. Make 
                    I. ExceptionLess
                    i. Labels

       =====  IV. Persistent containers ======

   34. Lazy
   35. List 
            A. ExceptionLess
            B. Labels
   36. Map 
            A. Make 
                    I. ExceptionLess
                   II. Labels
   37. Option 
            A. Labels
   38. PMap
   39. PSet
   40. RefList 
            A. Index
   41. Queue
   42. Ref
   43. Set 
            A. Make 
                    I. ExceptionLess
                   II. Labels
   44. Stack
   45. Stream  
             ===== V. Data =====
   46. Unit  
             ==== V.1. Logical ====
   47. Bool
   48. BitSet  
             ==== V.2. Numeric ====
   49. Numeric (Interfaces for number-related stuff)
   50. Big_int
   51. Common
   52. Complex
   53. Float
   54. Int
   55. Int32
   56. Int64
   57. Native_int
   58. Num
   59. Safe_float (placeholder)
   60. Safe_int  
             ==== V.3 Textual data ====
   61. Text (Definition of text-related interfaces)
   62. Buffer
   63. Char
   64. UTF8
   65. Rope
   66. UChar
   67. String
   68. StringText (A module containing aliases to String and modified
   69. RopeText (As StringText but with implementations from Rope and
   70. UTF8Text (As StringText but with implementations from UTF8 and)
            A. Labels

             ===== V. Distribution-related stuff =====
   71. Packages
   72. Compilers  
             ===== VI. Internals =====
   73. Gc
   74. Modules
   75. Oo 
            A. Private
   76. Weak 
            A. Make

             ===== VIII. Network (placeholders) =====
   77. URL
   78. Netencoding 
            A. Base64
            B. QuotedPrintable
            a. Q
            b. URL
            A. Html

             ==== VIII.1. Http ====
   79. Http
   80. Http_client
   81. Cgi_*
   82. Httpd_*
   83. MIME  
             ==== VIII.2. Ftp ====
   84. Ftp_client  
             ==== VIII.3. Mail ====
   85. Netmail
   86. Pop
   87. Sendmail
   88. Smtp  
             ==== VIII.4. Generic server ====
   89. Netplex_*  
             ==== VIII.5. RPC ====
   90. Rpc_*  
             ==== VIII.6. Languages ====
   91. Genlex
   92. Lexing
   93. CharParser
   94. UCharParser
   95. ParserCo 
            A. Source
   96. Parsing
   97. Format
   98. Printf
   99. Str
  100. PCRE (placeholder)
  101. Scanf 
            A. Scanning
  102. SExpr  
             ===== IX. System =====
  103. Arg
  104. File
  105. OptParse 
            A. Opt
            a. OptParser
            b. StdOpt
  106. Path
  107. Shell
  108. Unix 
            A. Labels
  109. Equeue  
             X. Unclassified
  110. Digest
  111. Random 
            A. State
  112. Date (placeholder)

Notes from testing OCaml 3.11.0+beta1 on Fedora


Richard Jones said:
Fedora compiled most of our OCaml packages for 3.11.0+beta1 now.  Here
are my notes on this, which I hope prove helpful for anyone else
trying out 3.11.

Firstly you can get any of the packages / patches we are using through
our CVS repo here:

Packages _other_ than those listed below built without any problems
and are available from my temporary repository
(  They will
eventually get built in Fedora 11.  Fedora 10 (released next week)
will continue to be based on OCaml 3.10.2.

Base ocaml package

Here are the patches we are carrying (NB especially patch 6):

Patch0:         ocaml-3.11.0-rpath.patch
Patch1:         ocaml-user-cflags.patch
# Support for PPC64 platform by David Woodhouse:
Patch3:         ocaml-3.11.0-ppc64.patch
# This is a patch from upstream which fixes PR#4637, PR#4582.
# commonly manifested as errors thrown saying:
# Invalid_argument("String.index_from")
Patch6:         ocaml-3.11.0-string-index-from.patch

These are the patches we have removed since 3.10.2, which we believe
are no longer necessary:

# Patch to work with new TCL versions:
#Patch2:         ocaml-3.10.0-tclver.patch
# Not needed because the GC allocator was completely rewritten:
#Patch4:         ocaml-3.10.1-map32bit.patch
# A similar fix went upstream in 3.11.0:
#Patch5:         ocaml-3.11-dev12-no-executable-stack.patch


Camlp4 parsing problem:

Build runtime/print_xml.cmx
File "runtime/", line 110, characters 35-37:
Parse error: [expr level ;] expected after "in" (in [expr])
File "runtime/", line 1, characters 0-1:
Error: Preprocessor error
*** [runtime/print_xml.cmx] Error 2


Small patch required, sent upstream (see our CVS).


Strange camlp4 problem, not yet resolved.  Maybe just a missing

OCAMLC    lib/pp.mli
OCAMLC4   lib/pp.ml4
sh: camlp4o: command not found
File "lib/pp.ml4", line 1, characters 0-1:
Error: Preprocessor error


Since we upgraded to camlimages 3.0.1, freetennis is looking for a
library called ci_core.cmxa which no longer appears to exist.
Upstream seems to be dead on this one.


Small patch required to fix a camlp4 parsing problem, not yet upstream
(see our CVS).


Build system failure - I didn't look very closely at this yet.


There seem to be a number of build problems with the 1.0 release of
ocamlgraph.  I'm not sure if these are related to 3.11.0 or not.


Undefined reference to caml_sync.  Not looked into this yet.


Stricter module naming restrictions in 3.11:

ocamlc -warn-error AX -g  -pp 'camlp4orf -I . pa_monad.cmo' -c
File "", line 1, characters 0-1:
Warning X: bad source file name: "Pythagorean-triples" is not a valid module name.
File "", line 1, characters 0-1:
Error: Error-enabled warnings (1 occurrences)

type-conv & sexplib

These work fine, but you must upgrade to the latest versions.


camlp4 parsing problem, not yet resolved.



Julien Sylvestre announced:
MLstate - currently in stealth mode - is an IT company, whose functional
programming approach to SaaS and cloud computing has been recently
recognized by the French Ministry of Research Innovation Award.

We are research-oriented, we value technical excellence and innovation
and we believe our technology has a potential to dramatically change the
way web applications are being built.

MLstate opens several new permanent positions to meet this challenge:

- Senior Developers: Outstanding PhDs with at least 3 years of research
experience in functional languages and/or formal verification and the
ability to manage a small technical team.

- Developers: PhDs with strong FP skills. Applications from PhD students
defending their thesis soon and who should not be reading the caml list
right now... are welcome.

Jobs are based in Paris and include a competitive compensation package.

Please send a (link to your) CV to

Manipulating xml files withing ocaml


Jean Krivine asked and Romain Beauxis replied:
> Just a quick question, I would like to open and access easily an xml 
> file within my ocaml program. Does someone have a small library that 
> would help me doing that?  All the things I found for now are 
> libraries that help me construct xml and check for consistency which 
> is not what I want. 

If the xml you intend to parse is not too broken (like html for instance), 
you can try to use xml-light, whose APIis very simple. 
The link:
Adrien Nader then said and Dario Teixeira replied:
> PXP may be a better choice. It's harder at first, but 
> not much and 
> could be worth the five additionnal minutes required to 
> learn it. It 
> handles unicode and is still maintained (among others). 

Indeed.  If you find yourself routinely having to deal with XML, 
and if you need more advanced features such as validating very 
complex DTDs, than learning PXP is well worth it (Xml-light 
will choke on all but the simplest DTDs). 

If you are doing heavy manipulation of XML and wished for a 
more "native" support in the language, then take a look at 

Finally, if you just need to parse a simple XML file and this 
is a one-off event, then Xml-light is indeed the simplest option.
Jake Donham then added:
One more choice is Xmlm:

It is simpler than pxp and more complete/correct than xml-light.

Kaputt 1.0 alpha


Xavier Clerc announced:
This post announces the 1.0 alpha version of Kaputt.
Kaputt is a testing tool for the Objective Caml language.
Home page:

 - assertion-based tests (inspired by the xUnit tools):
    the developer writes assertions by explicitly stating
    input and waited output values for the tested function;
 - specification-based tests (inspired by the QuickCheck tool):
    the developer writes (using combinators) a specification
    of the tested function and asks the library to randomly generate
    tests cases.

 - Objective Caml 3.10.2

Planned features:
 - more combinators and predicates (e.g. over Map, Set, etc.);
 - generalization of generator to accept other sources (e.g. streams).

This is clearly alpha work, so any suggestion/criticism will be
welcome in order to enhance/correct it.
Stefano Zacchiroli then said:
You are probably aware of oUnit [1] which, AFAIK, was the only testing
library available for OCaml thus far. Hence I guess you developed
Kaputt to achieve something which was not possible with oUnit or to
achieve it somehow differently.

Can you please comment over the differences between Kaputt and oUnit?

I'm quite sure it would be interesting for a lot of us.


Xavier Clerc then said and Stefano Zacchiroli replied:
> I was indeed aware of oUnit when I started working on Kaputt.
> The initial intent was to provide OCaml with something along
> the lines of the QuickCheck library developed for Haskell
> ( Clones of QuickCheck
> exist for various languages (
> but not for OCaml,

Actually I posted a few years ago a small module imitating parts of quicheck:

Apparently they even now use my ugly file in the Janet Street Core Library.

> even if a QuickCheck equivalent is provided by the Reins library
> (

I didn't find much in this ocaml reins library ... and it
looks quite heavy in functors ...

Your library looks very good, very clean. I just noticed you missed 
the 'pair' and 'tuple' random generators.

One criticism is that like many other libraries, such as oUnit, 
ocamlcalendar, they seem a little bit heavyweight. You got hundreds
of functions, 5 modules ... 

> Put shortly, the idea of QuickCheck is to encode the specification
> of a function using predicates and to ask the framework to generate
> random test cases to check that the function adheres to its specification.
> After designing this part of the library, I realized that it would
> be quite annoying (at least for me, the very first user) to have
> two libraries to code my tests. That's why I decided to add to Kaputt
> the functionalities found in oUnit.
> In summary: Kaptt = oUnit + {QuickCheck part of Reins}.
> People may get angry at such effort duplication, and I would understand
> it. My point is to put forward a unique library specialized in testing.

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