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

[Gerd Stolpmann <gerd@gerd-stolpmann.de>]

On Tue, 03 Apr 2001, Jacques Garrigue wrote:
>Last message before I make a needed pause, since I think lots of
>people are already discarding this thread anyway.

As I saw that many messages, I skipped the thread first. But I know it's
important... Sometimes it is better to wait until the direction of the
discussion becomes clearer.

I must admit that I never _decided_ whether to use classic mode or label mode;
I had my code base, and when O'Caml 3 was introduced I took the simplest way to
maintain my code. That was classic mode, because labels mode was incompatible
to previous versions of O'Caml. I began to use optional arguments, and from
time to time I also assigned labels to non-optional arguments. Even more seldom
I wrote labels at applications. (I _am_ an incremental learner.)

So I am a 50% classic mode user. 50% because I think labels are useful in
signatures (as documentation), but I can live without labels in
implementations. In my opinion, a (non-optional) "labels are comments in
signatures" mode would be right (i.e. nolabel mode). However, there is an
argument against this type of nolabel mode.

As a "library provider" I see the following problem with such a mode (and with
the current classic mode, too): I'm sometimes assigning too many labels, as in:

val f : ?optional:s -> nonoptional:t -> u

This is very natural if your main intention is documentation. But:

In classic and nolabels mode, the ~optional argument is really optional
because you don't apply the ~nonoptional argument with a label. But in labels
mode, you must pass the optional argument in order to execute the function.
Okay, the compiler prints warnings in such cases, but as a classic/nolabel
user I can ignore them. So I fear that libraries provided by users such me tend
to have pitfalls for labels users.

Because of this, I suggest that the compiler enforces that non-optional
labels are either turned on or off: If the .ml file is compiled with labels
turned off, the .mli file must not contain labels. If the .ml file is compiled
in label mode, it is accepted that the .mli file contains labels. So I am no
longer allowed to mix labeled declarations/definitions and unlabeled
applications in an insane manner.

Note that it is still possible to _use_ a labeled library in nolabel mode; in
this case all the labels are ignored.

>I just repeat here what was my last proposal, since it was in the
>middle of a mail, and some interested people may have not read it.
>At least, they don't seem to have read it.
>(It's only a personal idea.)
>
>* make label mode the default mode

Which mode is the default is very important. Users tend to keep the default
mode; so this mode will be used more frequent than the other mode. However, I
think we should not discuss about this point politically (i.e. who wins the
default mode wins the battle). Only a remark...

>* keep a nolabel mode similar to current classic mode, but not
>  allowing non-optional labels in function calls

As I already explained, I suggest to disallow non-optional labels in
abstractions and in signatures, too. This ensures that a library
written in any of both modes can be used in programs using the other mode in a
sane way.

>* remove all labels from the standard library

The standard library can remain labeled, because a nolabel user sees a view of
the standard library where all non-optional labels are stripped. But the stdlib
must itself be written in label mode.

>* introduce a module StdLabels containing labelized versions of List
>  and Array for labellers
>* add some extra labelized versions of a few functions: 
>  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'.

This looks very ugly. 

>Remark that this does not change anything for people who didn't use
>labels before: label mode is a conservative extension of ocaml 2, so
>you don't even need to use the nolabel mode.

Fully agreed.

To summarize my suggestion:

- Two modes as before, but with clear roles: 
  - nolabels mode: Non-optional labels are totally forbidden. Neither
    abstractions nor applications nor mli files must contain labels. Optional
    labels are possible. When calling a library written in label mode, the
    arguments are identified by position nevertheless.

  - labels mode: Can remain as it is.

- Standard library: Is written in label mode, and has a labeled signature.

- Default mode: Is the nolabels mode because this mode is backward-compatible
  to O'Caml 2 and all 0% classic mode users (those who never use labels in
  their own abstractions nor in applications)

I think most current classic mode users can live with this. The difference
between these nolabels and labels modes is bigger than in the current
version of the language, as both modes emphasize their view on argument
handling. This may motivate people to switch from nolabels to labels mode,
because there is a real benefit from it. (You get the labels only if you
switch, even if your motivation for labels is code documentation and not the
possibility of commutation.)

A last thought: The nolabels mode should be called positional mode; "nolabels"
sounds very negative and one may associate with this name that its support will
end in the near future. (I also thought about a better name for label mode
because many people on the list were confused from the fact that it only changes
the meaning of non-optional labels. "Commuting non-optional labels mode" is too
long. But renaming the classical mode has an impact on that, too.)

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr