Previous week Up Next week


Here is the latest Caml Weekly News, for the week of 29 March to 05 April, 2005.

  1. call for papers ML Workshop 2005
  2. IFL'05 - preliminary CFP
  3. output type
  4. Releases of ocamldbi, perl4caml, mod_caml, cocanwiki
  5. mbox-cleaner 1.0.0
  6. Parser combinators
  7. select (or polling) on in_channel?

call for papers ML Workshop 2005


Xavier Leroy announced:
                     Preliminary Call for Papers

                 The 2005 ACM SIGPLAN Workshop on ML


               To be held in conjunction with ICFP 2005
                          September 29, 2005
                           Tallinn, Estonia

The ML family of programming languages, whose dialects include
Standard ML, Objective Caml, Alice ML and nML, has inspired a
tremendous amount of language research, ranging from type inference
to module systems to operational semantics and implementation.
Languages from the ML family have alse been successfully applied in
areas ranging from compilers and theorem provers to low-level system
software, web applications and video games.

The goal of the Workshop is to provide a forum for researchers,
developers, and users to hear about and discuss the latest work on the
use, design, and implementation of ML-like languages.  Previous ML
Workshops have been held in Edinburgh, Pittsburgh, San Francisco,
Orlando and Baltimore.

The 2005 Workshop will be held in conjunction with the ACM SIGPLAN
International Conference on Functional Programming (ICFP) in Tallinn,
Estonia. We seek papers on any ML-related topic, including (but not
limited to):

* applications
* extensions: objects, classes, concurrency, distribution and mobility, 
    semi-structured data handling, etc.
* type systems: inference, modules, specification, error reporting, etc.
* implementation: compilers, interpreters, partial evaluators,
    garbage collectors, etc.
* environments: libraries, tools, editors, debuggers, 
    cross-language interoperability, etc.
* semantics

Submitted papers should describe new ideas, experimental results, or
informed positions regarding proposals for next-generation ML languages.
In order to encourage lively discussion, submitted papers may describe
work in progress.  Proceedings will be published as a volume of
Electronic Notes in Theoretical Computer Science (ENTCS).

General Chair:
    Matthias Blume, Toyota Technological Institute at Chicago

Program Chairs:
    Nick Benton                         Xavier Leroy
    Microsoft Research Limited          INRIA Rocquencourt
    7 J J Thomson Avenue                B.P. 105
    Cambridge CB3 0FB                   78153 Le Chesnay
    United Kingdom                      France
    E-mail:          E-mail:

Program Committee:
    Nick Benton (co-chair)        Microsoft Research
    Matthias Blume                Toyota Technological Institute at Chicago
    Martin Elsman                 IT University of Copenhagen
    Jean-Christophe Filliâtre     CNRS, University Paris Sud
    Robert Harper                 Carnegie Mellon University
    Xavier Leroy (co-chair)       INRIA Rocquencourt
    Chris Okasaki                 United States Military Academy
    John Reppy                    University of Chicago
    Andreas Rossberg              Universität des Saarlandes
    Zhong Shao                    Yale University
    Eijiro Sumii                  University of Pennsylvania
    Stephen Weeks
    Kwangkeun Yi                  Seoul National University 

Important Dates:
    * Submission Deadline: June 10, 2005
    * Notification of acceptance: July 15, 2005
    * Final paper due: Sept 5, 2005
    * Workshop: September 29, 2005


The Workshop proceedings will be published as a volume of Elsevier
Electronic Notes in Theoretical Computer Science (ENTCS). A
preliminary proceedings will also be distributed at the Workshop.

Submission Procedure:

Contributions, in English and not to exceed 14 pages in ENTCS format,
should be submitted via the Web interface at by Friday, June 10, 2005.

Submissions must be in PDF or Postscript form. The Postscript
should be interpretable by Ghostscript, use standard fonts (or include
the necessary fonts), and print correctly on US letter paper (8.5x11
inches). Use of the ENTCS style files (available from the workshop Web
site) for initial submissions is strongly encouraged.

Notification of the acceptance or rejection of papers will be given by
Friday, July 15, 2005.

IFL'05 - preliminary CFP


Andrew Butterfield:
= Preliminary Call for Participation =

Announcement and Call for Papers for the 17th International Workshop
on the Implementation and Application of Functional Languages (IFL'05)

September 19th-21st, 2005, Dublin, Ireland.

== Scope and Topics ==

The IFL workshops form a tradition that has lasted for nearly two
decades. The aim of these workshops is to bring together
researchers actively engaged in the implementation and application
of functional and function-based programming languages. They
provide an open forum for researchers who wish to present and
discuss new ideas and concepts, work in progress, preliminary
results, etc. related primarily but not exclusively to the
implementation and application of functional languages.

Topics of interest include, but are not limited to
  * language concepts
  * type checking
  * compilation techniques
  * generic programming techniques
  * (abstract) interpretation
  * automatic program generation
  * (abstract) machine architectures
  * formal aspects
  * array processing
  * concurrent/parallel programming
  * concurrent/parallel program execution
  * heap management
  * runtime profiling
  * performance measurements
  * debugging and tracing
  * verification
  * tools and programming techniques

Papers on applications demonstrating the suitability of
novel ideas in any of the above areas and contributions on related
theoretical work are also welcomed. The change of the workshop name
adding the term "application", introduced in 2004, is to reflect the
broader scope IFL has gained over recent years.

== Contributions ==

Prospective authors are encouraged to submit papers to be published in
the draft proceedings (published as a technical report of the
Department of Computer Science of the University of Dublin) and to give
presentations at the workshop. All contributions must be written in
English, conform to the Springer-Verlag LNCS series format, and not
exceed 16 pages.

Papers must be submitted by August 26th as
postscript or pdf files through the workshop web page at .

All participants who give presentations at the workshop are
invited to submit revised versions of their papers for the
post-workshop proceedings. They will be refereed by the program
committee according to normal conference standards.

== Important Dates ==

  * Jul  8th, 2005 Campus Accommodation deadline
  * Aug  7th, 2005 Registration deadline
  * Aug 26th, 2005 Submission deadline for draft proceedings
  * Sep 19th, 2005 Workshop starts in the morning
  * Sep 20th, 2005 Afternoon excursion and banquet dinner
  * Sep 21st, 2005 Workshop ends in the evening
  * Nov  7th, 2005 Submission deadline for post-refereeing process
  * Dec 16th, 2005 Notification of acceptance/rejection
  * Feb  3rd, 2006 Camera-ready papers due

== Program Committee ==

  * Matthias Blume, Toyota Technological Institute, Chicago, USA
  * Andrew Butterfield,  (Chair) Trinity College Dublin, Ireland.
  * Clemens Grelck, University of Lubeck, Germany.
  * Zoltan Horvath, Eotvos Lorand University, Hungary.
  * Frank Huch,  University of Kiel, Germany.
  * Joe Kiniry, National University of Ireland, Dublin.
  * Hans-Wolfgang Loidl, University of Munich, Germany.
  * Frederic Loulergue, University of Paris XII, Val de Marne, France.
  * Simon Marlow, Microsoft Research, Cambridge, UK
  * Marco T. Morazan, Seton Hall University, NJ, USA.
  * Barak Pearlmutter, National University of Ireland, Maynooth.
  * Rinus Plasmeijer, Radboud Universiteit Nijmegen, Netherlands.
  * Peter Thiemann, University of Freiburg, Germany.
  * German Vidal, Technical University of Valencia, Spain.
  * others to be confirmed

== Workshop Organization ==

Andrew Butterfield,
Department of Computer Science,
University of Dublin.

== Further Information ==

Website: E-mail: output type


Alex Baretta asked and Xavier Leroy answered:
> currently returns an int. Intuitively it would be 
> more appropriate for it to return a union type such as the following.
> type comparison_result = Less | Equals | Greater
> What are the reasons behind the present design choice?

It's a historical error.  If I were to do it again, I'd use a sum type
such as your "comparison_result".  The current solution allows to use
(-) (integer subtraction) as the comparison predicate for *small*
integer arguments, but this doesn't work as a general integer
comparison because of subtraction wrapping around for large arguments.
So, there are really no benefits to encode the result of a 3-way
comparison as an "int".
The thread having moved off-topic, Jon Harrop asked and Jacques Carette answered:
> Would someone be so kind as to enlighten me (and probably a few other people!) 
> as to what these intruiging GADT things are and what they're good for? :-)

They are a (conservative) extension to Algebraic Data Types (and G=Guarded or
Generalized, depending on the author).  The basic idea is that instead of
giving names to the various constructors in a Sum type, you give explicit
functions which become the constructors.  Furthermore, you then make type
inference context-dependent: the type of each constructor is inferred
independently, and can have different 'guards'.  

Or at least that's my quick-and-dirty impression, which definitely contains
technical inaccuracies, but is roughly right.  To get a good introduction, why
not turn to
for a pleasant and informative read.  The slides give references as well as
example applications.

For more information: (and several more at   [tougher read...]

For interesting but serious discussions:

The most convincing example I have seen is that an eval function for a
statically-typed language
let rec eval e = 
   match e with 
     | Lit n -> n
     | Plus(a,b) -> (eval a) + (eval b)
     | True -> true
     | False -> false
     | And(a,b) -> (eval a) && (eval b)
     | If(t,c,a) -> if eval t then eval c else eval a
     | IfZero e' -> (eval e') = 0
is currently rejected in ML languages, but with GADTs the above can be
accepted, as it can't "go wrong".
Brian added:
   In addition to the sources Jacques provided, let me point you to

for a very readable description that doesn't rely on heavy type theory to get
the idea across.

I wonder, if you really want to use this approach for genericity on, say
numeric types, if you need something like Haskell's newtype (and a guarantee
that the constructor get optimized away) to make it useful?

Releases of ocamldbi, perl4caml, mod_caml, cocanwiki


Richard Jones announced:
I'm pleased to announce the following releases, which are all just for
bug fixes and stability.

OCamlDBI 0.9.11
  What: A database independent RDBMS API.
  License: LGPL

perl4caml 0.9.3
  What: A way to call Perl code and libraries from OCaml.
  License: LGPL

mod_caml 1.3.6
  What: OCaml bindings for the Apache API.
  License: LGPL

cocanwiki 1.3.11
  What: A full-featured Wiki and CMS written in OCaml.
  License: GPL

You can find Debian packages for a lot of this stuff here:

(I have Debian packages for pretty much everything, so ask me if you
can't find one for what you need).

mbox-cleaner 1.0.0


Oliver Bandel announced:
After working on it again, the mailbox-cleaner-tool,
which throws away doublettes of mails (comparing
body-contents), is now available on ftp as
version 1.0.0.

It's a small tool, but if you have mutiple copies of mails in your
mail-folder, it is helpful to you.

It reads from stdin and writes to stdout.

You can download it here:

Have fun with it. :)

Parser combinators

Alex Baretta asked and Jacques Garrigue answered:
> Er.. Excuse me for sticking my nose into this, but I think I read 
> something interesting. Parser combinators? What do you mean? I'm quite 
> sure I have not seen any operators acting on stream parsers, at least if 
> by stream parsers you mean the LL1 based on pa_op.cmo camlp4 module.

The point is that you can define them yourself.
For instance here is the star operator.

let rec star ?(acc=[]) p = parser
    [< x = p ; s >] -> star ~acc:(x::acc) p s
  | [< >] -> List.rev acc

More concretely, here is another version of expression parsing, using

type expr =
    Num of int
  | Var of string
  | Plus of expr * expr
  | Mult of expr * expr

open Genlex

let rec accumulate parse accu = parser
  | [< e = parse accu; s >] -> accumulate parse e s
  | [< >] -> accu
(* val accumulate : ('a -> Genlex.token Stream.t -> 'a) ->
                    'a -> Genlex.token Stream.t -> 'a *)
let left_assoc parse op wrap =
  let parse' accu =
    parser [< 'Kwd k when k = op; s >] -> wrap accu (parse s) in
  parser [< e1 = parse; e2 = accumulate parse' e1 >] -> e2
(* val left_assoc : (Genlex.token Stream.t -> 'a) ->
       string -> ('a -> 'a -> 'a) -> Genlex.token Stream.t -> 'a *)
let rec parse_simple = parser
  | [< 'Int n >] -> Num n
  | [< 'Ident x >] -> Var x
  | [< 'Kwd"("; e = parse_expr; 'Kwd")" >] -> e
and parse_mult s =
  left_assoc parse_simple "*" (fun e1 e2 -> Mult(e1,e2)) s
and parse_expr s =
  left_assoc parse_mult "+" (fun e1 e2 -> Plus(e1,e2)) s
(* val parse_simple : Genlex.token Stream.t -> expr
   val parse_mult : Genlex.token Stream.t -> expr
   val parse_expr : Genlex.token Stream.t -> expr *)

let lexer = Genlex.make_lexer ["+";"*";"(";")"]
let parse_string s =
  match lexer (Stream.of_string s) with parser
    [< e = parse_expr; _ = Stream.empty >] -> e
(* val parse_string : string -> expr *)

I leave as exercise how to extend it to handle "-" and "/" in a
generic way.

select (or polling) on in_channel?


Eijiro Sumii asked:
Is there any easy way to _correctly_ do a "select" (as in the UNIX
system call) on Pervasives.in_channel?  My naive approach [Unix.descr_of_in_channel ic] [] [] 0.

seems to fail (and it indeed does fail) because of the buffering
inside Pervasives.in_channel, as long as I checked the source code of
ocaml-3.08.3.  Pervasives.in_channel_length doesn't help in my case
since the input channel is not a file.  Should I use only the
low-level functions in the Unix module if I _ever_ want "select"?
Gerd Stolpmann answered and Eijiro Sumii replied:
> Yes. The point is that you cannot interpret the result of in
> a reasonable manner. When says the descriptor has no data,
> it might still the case that there are data in the buffer.

Yes, this is what I thought.

> If the descriptor has data, you don't know when they are exactly
> read into the buffer.

Here I don't quite understand what you mean - does this issue per se
prevent us from polling an in_channel?

> I don't understand why you mention in_channel_length here.

If the channel were a (binary) file, I could use in_channel_length to
know how many bytes I should read (by Pervasives.really_input, for

> What is your real problem?

In my program, I need to wait _only for 60 seconds_ for data from a
channel created by Unix.open_connection.  For this purpose, something
like would be the best if it worked.

Assuming that no such function like exists for
Pervasives.in_channel, I've written the following ad hoc external
function, which can be used (in combination with to
achieve similar effects.  Of course, it might be unsafe if the channel
structure is different in other versions of OCaml.  Any better idea,

#include <sys/types.h>
#include <caml/mlvalues.h>

/* adapted from ocaml-3.08.3/byterun/io.h */
struct channel {
  int fd; off_t offset;
  char * end; char * curr; char * max;
  void * mutex; struct channel * next;
  int revealed; int old_revealed; int refcount;
  char buff[0];
#define Channel(v) (*((struct channel **) (Data_custom_val(v))))

value in_channel_is_empty(value vc) {
  struct channel *c = Channel(vc);
  return Val_int((c->curr >= c->max) ? 1 : 0);
Eijiro Sumii said and added:
P.S.  I've also received an e-mail informing me that Cash

has such a function.  It looks nice, but having it in pure/core OCaml
would be even nicer.

Eijiro Sumii wrote:
> Thanks to everyone for ideas on how to "select" Pervasives.in_channel.
> Since there seems to be no better solution than
>   (1) hacking the low-level structure by using external C, or
>   (2) reinventing the high-level library on top of Unix I/O,
> I'm thinking of submitting a feature wish at
> .  It should be easy enough for
> the developers to implement, I hope...  (I could contribute my own
> implementation if necessary, but I'm sure they will do better work.)
Alex Baretta answered:
I have not been following this thread closely, so I did not answer earlier. My
impression is that select and buffered IO are concepts that do not live well
together. I This is probably the reason the Caml team has for not implementing
such a feature in the Pervasives channels API.

I would attempt to model the problem in a multithreaded paradigm, where the the
"selecting" is implicit in the thread scheduling mechanism. Of course, if you
allow the use of threads, the selecting on channels becomes fairly trivial.

let (++) x f = f x

let input_string =
  let buf =  String.create 1024 in
    fun ic ->
      let bytes = input ic buf 0 1024 in
        String.sub buf 0 bytes

module IO_manager = struct
  type tio_manager = string
  let wrap_in_channel (evch : io_manager) (ic : input_channel)=
    let rec cycle () =
      ic ++ input_string ++ Event.send ++ Event.sync;
      cycle ()
    in Thread.create cycle ()

Of course, this is a very rough sketch of message_passing API based on the
Event module, encapsulating the select facility on top of an input_channel.
Actually, ic could be any resource the program might need to synchronize on.

Let me add that Baretta DE&IT is using this paradigm to multiplex IO from/to
different field buses in its Ocaml based, SoftPLC / SoftCNC kernel.
Kevin Sejourne also replied:
I'm not sure of what you want, but does this do the job?
let système command f_line = 
  let cin = Unix.open_process_in command
    (try while true do
      f_line (input_line cin);
    done with | End_of_file -> ());
  Unix.close_process_in cin
It is just a function that give to 'f_line' evry 
lines produced by a pipe by the 'command'.

I use it for Xdialog2Ocaml

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