Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: to have labels or not
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2000-03-24 (15:48)
From: Jacques Garrigue <garrigue@k...>
Subject: Re: to have labels or not
From: Max Skaller <>

> The arguments about the standard library seem to me to be this: some of
> the
> ocaml (classic) users like myself would prefer to move to the
> modern/strict/label
> mode and get rid of the classic mode. But we're not willing to do so if
> it
> clutters our use of the standard library.

This is a reasonable argument.  However, by discussing with olabl
users (many of them being originally ocaml users) I really got the
feeling that the fact to have to write labels for standard library
functions didn't bother them. I wouldn't be honest if I don't admit
that there are some exceptions, but then everybody cannot agree on
everything. And olabl didn't provide anything similar to classic mode,
just a raw compatibility mode in which you couldn't use optionals at

So before deciding whether you want to stay classic or go to commuting
label mode, you might just give it an (extensive enough) try.

By the way, it seems that there will be less labels in the standard
library in 3.00.

> I do not feel I gain the real advantage of labels with GUI/PCRE
> type libraries _unless_ the labelled optional argument things
> commute. I also don't want to clutter use of simple
> standard library  functions with labels.

Here is probably the biggest misunderstanding.
In classic mode, optional arguments _do commute_.
Only non-optional and unlabelled ones do not.
And I would say that for most people (at least those with a pure ocaml
background), the only commutations that matter are those between
optional arguments.

Remark for instance that Markus Mottl himself explained that he was
using only classic mode.

> So here's a suggestion. Get rid of classic mode.
> But have TWO complete standard libraries:
> 	module Classic = .. put classic modules here ..
> 	module Olabl = put labelled versions here

We thought about that.  And even tried it before releasing 2.99.
I am the one who pushed against this solution, because I felt this
would really cause a community split.

The problem is not just the standard library.
If you do not have classic mode, then it means that everybody will
have to write all labels. If you have a look at LablGL, you will see
that I use there plenty of non-optional labels, and very few optional
ones. I'm pretty sure people would start asking me to remove them.

On the contrary, if you have classic mode, even classic mode users can
add documenting labels to their interfaces.  And then commuting label
mode users can use these labels to pass arguments in the order they
The whole point is: the user (not the implementor) should decide.
And in practice it is better to decide on a program-wide rather than a
per-module basis (as some suggested).

In extreme cases where you want to mix both modes in the same program,
you can do it on a per-file basis.  This is not encouraged, but there
are well-defined semantics as long as you write a .mli file (or check
types in the .cmi file).  I really think that being able to switch in
the middle of a file would be dangerous.  I'm already sometimes
confused by such uses of "open".

The only weakness of this approach is if you copy some code from a
file in classic mode to one in commuting label mode (or reverse).
Then you have to add/remove labels by hand.  But then this is also a
way to understand the code better :-)
It might also be possible to develop a tool to do that semi-
automatically. In fact Jun Furuse has been asking for it for a long
time, but I think he is big enough to be able to do it himself :-)

Best regards,