As a long time user of OLabl, I was very happy when the ``great merger''
was announced. I was also very happy that there were quite a few
very positive reactions on this list, and that there was the understanding
that the merger should serve both those who wanted to stay in their old
worlds, be it the world with or the world without labels
(by making libraries written in the other world accessible to them),
and those who wanted to do some border-crossing.

In the last few days, however,
the tone seems to have changed considerably ---
before a religious war breaks out,
I would recommend reading ``Nathan der Weise'' by Lessing ;-)


More to the point:

Pierre Weis <Pierre.Weis@inria.fr> writes:
 > I'm afraid I don't agree with you: commuting between arguments is not
 > worth the extra burden of having labels, I'm not sure it is even
 > desirable. I think that when arguments of a function are not always
 > passed in the same order the readibility of the code is jeopardized.

To me, for some functions the arguments are in the wrong order
whichever order you put them.
Even for some functions in the standard library.

So when writing applications of these functions,
I have to look them up anyway --- and for me it is faster
to do this via LablBrowser/CamlBrowser than via the local
installation of the HTML version of the manual.

When reading the code, however, with labels
I do not have to look up the function at all!


I find code with heavy use of functions with more than three arguments
hard to read without labels --- no matter whether ML or Haskell.
I find myself routinely writing functions
with around ten non-optional arguments.
And I am glad that I can add another five optional arguments,
should the need arise,
to spare me the copy-and-paste of the function definition for a new variant.
I find labels indispensable for this.
I often do copy-and-paste for the labelled applications ;-),
and labels help to find the place to be changed.
But the real pay-off comes at the time of reading the code
(which I do, sometimes :-),
when I can read it without having to look up the definition.


Of course, there are other programming styles, too,
and very algebraic combinator-style programming
will profit much less from labels, and look nicer in classic style.


I love higher order functions, too, so initially the requirement
to do long eta normal forms seemed to be a drawback to me
just the same way as to some people on the list.


However, nowadays I find myself doing ``fold_right (+)'' much less
than ``fold_right myfunction'', where ``myfunction'' often is
a partial application of a more-argument function
that has been let-defined a few lines above ---
this application can still be multi-line,
but since the more-argument function has been let-defined for the purpose
of having its instances used in fold_right,
I find that adding this one extra label in the let-definition
does no harm at all, on the contrary,
it adds to the readability of the definition of the more-argument function.


So for me, labels have proved to be the right thing for what I do
with OCaml/OLabl --- but then, I do not claim to be a typical user:
When doing combinator-style programming, I prefer Haskell,
and, half joking, I consider OCaml/OLabl an imperative programming language
just by virtue of its not being purely functional
(I do not use other imperative programming languages,
 (except shells), and I also recommend my students not
 to use other imperative programming languages ---
 some even understand and follow :-).


Maybe the question to be discussed
is which kind of mixtures between the two styles
should be enabled by the compiler.
For my perception of OCaml-3.0, however,
I think it is sufficient if it just puts the two worlds
of no-label-users and label-users
on a common technical basis,
without forcing anybody to really change their style
(which is, as I perceive and understand it,
 the design philosophy followed so far).


Best regards,

Wolfram