Previous week Up Next week


Here is the latest Caml Weekly News, for the week of May 01 to 08, 2007.

  1. PML: a new language is being born
  2. lazy lists
  3. How to use C++ library in OCaml?
  4. Abstract types in the revised syntax
  5. Fedora/OCaml packaging discussion
  6. F#

PML: a new language is being born


Christophe Raffalli announced:
I am pleased to announce the first EXPERIMENTAL release of PML, 
an ML like programming language, which will be extended with a prover soon. 

In this release, only the programming language is implemented, but I 
am interested to hear remarks from the members of this list to try to 
get the best possible initial design. 

More information, development plan, download and manual are available at 

The main features of the language are: 
- great cartesian product unification (records, modules and objects are the 
same, arrays are missing and will not be unified) 
- polymorphic variant needing no type annotation (but it is a good idea to use 
- two kinds of inheritance: open inheritance and multiple (closed) inheritance 
(read the manual to know what this mean) both for records and pattern-matching 
which are dual in PML. 
- etc.

lazy lists


Loup Vaillant asked and Daniel de Rauglaudre answered:
> Regular streams are destructive. I was talking about "functional" 
> ones. I didn't try them myself, but the manual says one can perform 
> left recursion with them (thanks to their non destructive nature). 

Use camlp4s : the library "fstream" and the syntax extension "pa_fstream" 
are still there. Access and download from my home page below.

How to use C++ library in OCaml?


Guan asked and Roberto Bagnara answered:
> I'd like to use the Parma Polyhedra Library 
> ( to solve the convex-hull and widening 
> problems. Does it work in ocaml? Or any other good tools for ocaml? 

The CVS version of the PPL (what will become PPL 0.10) has an OCaml 
interface (in addition to C++, C, Prolog and Java interfaces). 
This version is not formally released yet, but you can obtain it 
by following the instructions at 

The OCaml interface has not been heavily tested yet, but we believe 
it works OK.  In any case, we will provide all the assistance 
you may need. 

> BTW, does ocaml work with the   
> LP_solver( library? Or is there any 
> good LP solver for ocaml? 

The same version of the PPL features also a Mixed Linear/Integer Programming 
solver based on exact arithmetic.  You can access it from all the interfaces, 
including the OCaml interface.

Abstract types in the revised syntax


Nicolas Pouillard explained:
This message concern the few people that use the revised syntax :) 

In the revised syntax, abstract types are expressed by defining them 
with an unbound type variable: 

(* Original *) 
type t;; 

(* Revised *) 
type t = 'a; 

The motivation is that looks like an existential type, which is a way 
of seeing abstract types. 

However I found this motivation misapplied since it doesn't look like 
an existential type, there is no exists keyword?!? (type t = exists 
'a. 'a;) 

It's like a hot-dog without sausage?!? 

In fact, consequences of that choice are worst. If forces the 
parser/printer to do some semantical operation to convert back and 
forth between syntaxes. 

type t 'a = 'a; (* not abstract *) 

type t 'a = 'b; (* abstract *) 

It was considered acceptable, since the test for the freeness of a 
single type variable seemed simple because very local. 

Indeed only the list of parameters was consulted to compute the 
freeness of the type variable. 

It seems very weak since highly dependent of future evolution of the language. 

Nowadays it's no longer sufficient. Constraints can be added with a 
type declaration to constrain the type of parameters. 

type c 'a = 'b 
   constraint 'a = < b : 'b; .. >; 
(* Thanks to Till Varoquaux for it's bug report. *) 

Clearly I don't want to push that wrong choice further by making more 
semantic analysis in the parser/printer. 

So I revert back to << type t; >> for abstract types. 

Now, what's the new representation for abstract types. OCaml use a 
option type, where None represent the abstract type. We can't afford 
that, since we want a concrete syntax for everything. 
However we have a nil type that can be used as a default case (for 
lists of types or optional types). 

<:sig_item< type t >> === <:sig_item< type t = $ <:ctyp<>> $ >> 

Not that this will also concern abstract module types. 

Alas, this will affect existing code using the revised syntax, but 
will be easily caught at compilation. 

>From a pragmatic point of view, a grep to show the usage of such types: 

grep -E "^[ \t]*type.*=[ \t]*'[^ \t]*[ \t]*;[ \t]*$" **/*.ml* 
Feel free to share your mind on that subject. The change is not yet 
applied to the CVS.
Till Varoquaux then asked and Nicolas Pouillard answered:
> BTW I still haven't figured out how to generate constraints (lets say 
> I have a list of strings [t1,..,tn] and a list of idents [], 
> how do I generate the type < c1:t1; ... ; cn:tn >? ) 

That way... 
open Camlp4.PreCast;; 

let mk_obj_type _loc fields types = 
  let object_type = 
    List.fold_right2 begin fun field typ object_type -> 
      <:ctyp< $lid:field$ : $lid:typ$ ; $object_type$ >> 
    end fields types <:ctyp<>> 
  <:ctyp< < $object_type$ > >> 

mk_obj_type ( "<test>") ["f1"; "f2"] ["t1"; "t2"];;

Fedora/OCaml packaging discussion


Richard Jones said:
Starting here:



In this thread, Don Syme said:
F# is a research language, with many of the same issues as other research 
languages (license, support, works poorly on some platforms). We never think 
of it as a replacement for OCaml, though it makes a reasonable alternative on 
Windows (less so on Linux). I guess as I researcher I think of both as 
stepping stones to other better and greater things. I want to see this class 
of languages live and flourish in many parts of the computing industry. Brian 
Hurt captured things well here. 

There is a overlap between the two (e.g. with Jon's work), but there is also a 
lot of synergy: I know OCaml is gaining traction in some financial companies, 
and I can't help think that the existence of F# helps this more than it 
hinders it. For example, it helps people make stronger arguments to 
management: easier to recruit programmers, gives a way for Java and C# 
programmers to retrain in steps. Also, I think an OCaml/F# mix would make an 
excellent university course, where each language alone would leave interesting 
issues unaddressed. Perhaps there is also scope for a dual-track conference on 
both languages. 

We've always tried very hard to avoid overlap. For example, you'll notice we 
don't announce F# releases on the OCaml list - this is out of respect for the 
OCaml community. Jon operates in both worlds and has books and products to 
sell, so will be naturally talking about and comparing both systems. I think 
that's a good thing, and I know he intends his comparisons to be informative 
rather than destructive. 

F# is an independent implementation: it wasn't derived from an earlier version 
of OCaml (we would have avoided zillions of bugs if we'd done that!). We try 
to arrange the libraries to get a reasonable degree of compatibility with 
OCaml 3.08, but are imperfect. We also aim to support cross compilation, 
though not perfectly (local adjustments to code may be required, and missing 
features avoided). We do use OCaml to bootstrap F# for a variety of reasons, 
though we are moving away from that model. 

Jon's assessment of performance under Mono hasn't been independently verified. 
Any particular performance problem really comes down to a Mono v. .NET issue. 
Jon should isolate the issue out in a C# program and report it to the Mono 
team: they will take it seriously. Other users of Mono do not report 
catastrophic performance problems (or else no one would use it!) 

We understand the current license doesn't meet the standards of the open 
source community. We have permission to release the source under a more 
permissive license quite similar to Iron Python, and plan to do that. However 
we probably won't make a big song-and-dance about that, as the way we have the 
project set up now (binary releases) is really ideal for us as a small team. 
But emitting the source code under a permissive license now and then makes a 
lot of sense in order to address some of the issues you mention below.

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