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

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

More answers, and more prespectives.
That's all very nice.

Globally it seems that almost everybody would prefer a single mode.
This is also my point of view: staying with two "equal" modes is
confusing.

Originally this was an attempt to keep most of the progress made in
olabl (with label mode) for people with an olabl background, while the
classic mode was intended to be the main mode for people used to
ocaml. I hoped that maybe just a few people might switch to label
mode, and more importantly classic mode users would start using labels
in classic mode. This is the lack of progress in this last direction
that makes me thing this will not work as well as I hoped: there is
little point in having labels in the standard library if most 3rd
party libraries do not labelize their APIs. Then it is better to have
one single community adapt slowly.

This said, at last we got an answer from a "happy classic mode user".
At least my attempt was not completely absurd :-)

From: "Yaron M. Minsky" <yminsky@cs.cornell.edu>
> I make heavy use of labels in classic mode both for the
> extra type safety it provides and for documentation.  I
> find it to be extremely useful, and would be sad to see
> classic mode go. I've never felt a great need for commuting
> of non-optional arguments.  LablTk, at least, seemed quite
> usable in classic mode.
> 
> The idea of stripping labels out of the standard library
> seems like a mistake.  The main thing I like about labels
> is the extra safety they provide.  For example, the ~key
> and ~data labels for the function in Map's iter is very
> useful, particularly when the key and data happen to be the
> same type.

Thank you very much. I was starting to feel a bit depressed about the
outcome of the classic mode.

Still, if there is only one mode to keep, I think it is better to keep
the label mode, both because it is more powerful (commutation matters
for some users) and because it is better understood theoretically
(cf. the silly soundness problem in classic mode).

But if we manage well the transition, I believe we can keep most of
the advantages of classic mode, while getting labels out of the way of
beginners.

First, concerning the standard library, an idea would be to first
remove all labels from the default versions, but then add labelized
versions of some specific functions with a different name (adding a
"'" for instance).
I mostly think of: Pervasives.output', Pervasives.input',
Pervasives.really_input', Array.blit', String.blit';
and maybe also String.sub', String.fill', Buffer.add_substring',
Hashtbl.add', Map.add'.
Since their number is very small, this would not mean too much code
increase.
If we have these functions, then labellers would probably be happy
with a Stdlabels module containing just labelized version of List and
Array. (Keeping this compatibility module small is good to avoid
confusion).

However, while the duplication approach (at a function or module unit)
seems to be the only possible for the standard library, it would be
awkward for other libraries.
So the next question might be, are people ready to have some mandatory
labels in the Unix library? And how much?
Removing labels from the Unix library makes code less redable, and
more error prone, particularly since many arguments have the same
type. (See how easier it was to understand the last code snippet
posted on this list, where Unix.create_process was used with labels.)

The graphics library being more beginner oriented, I'm not sure
keeping labels there would be a good idea.

Last, there would still be a "nolabel" mode left, but this would be
mostly for technical reasons, and would not be explicitly supported
anymore after a transition period.

Jacques Garrigue

P.S.
A few other points from the orginal poster.
> I agree that having ocaml have one standard mode would be
> best, if possible.  If there continue to be two modes, I am
> strongly in favor of a pragma for specifying the mode on a
> file-by-file basis.
Second request. If we stay with two "equal" modes, that may get
through.

> (On another note, it would be lovely if one of these days
> ocaml could move to something like the alternative syntax
> shipped with camlp4.  There are a number of bits of the
> caml syntax that are quite counterintuitive, most of which
> are fixed with the alternative syntax.)
That would be much harder for compatibility reasons.
Yet I understand camlp4 might get into the standard distribution.
Maybe not so nice for people attached to a unique mode, but if you
don't care that may become a real alternative.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr