Re: [Caml-list] Future of labels, and ideas for library labelling

[Xavier Leroy <Xavier.Leroy@inria.fr>]

Wow, what a lively discussion!  I waited for a while before jumping
in, to see as many opinions as possible, but actually the arguments
put forward are pretty much the same Jacques and the rest of us
discussed while designing the OLabl/OCaml merger that gave OCaml 3.00.
So, let me recapitulate the ideas behind this design (at least as I
remember them).

1- We wanted labeled and optional function arguments to be an
extension of the Caml language (just like objects, classes, and
modules to a very large extent), i.e. something that does not affect
the core ML language, and remain backward compatible with earlier
versions of OCaml.  I think this is crucial for two reasons.  First,
it must be possible to learn and teach OCaml incrementally, by
successive layers of increasing complexity.  Second, we happen to have
users that develop significant applications in OCaml, and changing the
language in incompatible ways every other year is a sure way to piss
them off.  We get enough criticism and suspicion about OCaml "changing
all the time"...

(One consequence of this requirement is the ~label:arg syntax, because
the label:arg syntax of OLabl and OCaml 2.99 was causing syntax
ambiguities with type constraints ident:type and thus breaking
backward compatibility.)

2- With the strict label semantics of OLabl or OCaml with the -labels
option (if a label is given in the function definition/declaration, it
must be used in all applications of that function), the only way to
achieve backward compatibility (point 1 above) is to have versions of
the standard libraries that are totally unlabeled.  Otherwise,
long-time Caml users would have to change every call to List.map in
their code, and teachers would have to teach labels very early.

Of course, having standard libraries completely unlabeled kind of
defeats the purpose of labels (i.e. self-documentation of library
functions and additional safety and flexibility at applications of
these functions), so Jacques' initial proposal was to have two
versions of the standard libraries, one with labels and one without.
But we quickly realized this was unfeasible.  It's just too hard to
maintain two versions of the same libraries.  And everyone who writes
a Caml library and wants it to be used as widely as possible while
taking advantage of labels would also need to maintain two versions.

3- Thus the "classic mode" was born as a way to have only one
(labeled) interface to a library, yet not force users of this library
to use labels at applications.  I really liked this idea of Jacques,
because we can put labels in the library interface to self-document
it, yet remain backward compatible with code using the library without
labels.  Of course, users that want the additional safety of labels
can provide them at application sites, where they will be checked by
the type-checker.  To me, this is an excellent compromise: while I
usually don't put labels at application sites, I enjoy the additional
documentation provided by labels in module interfaces.

4- Since we did not want to trash the OLabl approach immediately, the
"commuting label mode" was introduced to 1- implement stricter
checking of labels, making them mandatory at application sites if the
function was declared with labeled parameters, and 2- support giving
labeled arguments in a different order than in the function
declaration.  Actually, a third mode was considered that would
implement strict label checking but disallow commutation, thus
ensuring that a given piece of code would be correct under both label
semantics ("classic" and "commuting"), but we weren't sure this had
enough value to be implemented.

5- We considered putting compiler pragmas to select the label mode
inside the source, possibly changing it around a piece of code,
instead of a per-file compiler flag.  OCaml currently does not have
this notion of pragmas, and it is not completely clear how they
interfere with, say, submodules (can I put the pragma inside a "struct"?
if so, what it its scope?).  So I decided to wait until the need for
such a pragma was really apparent.  But it can be done if really necessary.


A year or so later, I'm still convinced this design is the most
reasonable approach.  Yes, having two modes is not nice, but it is a
lot less bad than the alternatives.  If one mode must go, I think it's
the "commuting label" mode because of the backward compatibility issue
(point 1) and the fact that multiple versions of the libraries are
infeasible (point 2).  

So, the real questions I have for readers of this list:

- How many of you use the "commuting labels" mode?
- For those who use it, do you take advantage of commutation or
  do you use it mostly to benefit from strict checking of labeled
  arguments?
- What is worse in your opinion: having two modes or removing the
  "commuting label" mode?

Apologies for this long rant.

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr