Re: Syntax for label, NEW PROPOSAL

[Damien Doligez <Damien.Doligez@inria.fr>]

First of all, I don't think I'm going to use label mode anytime soon,
but the same is true of objects, I haven't looked at variants yet, and
I consider higher-order functors an exotic feature that I'll probably
never need (and I do use double-semicolons).

But that's no reason to go to war against labels.  It's just I'm in
love with the small simple functional language that is at the heart of
O'Caml. As long as I can use it, I'm happy.

Now a few random comments on the discussion.


>From: Don Syme <dsyme@microsoft.com>
>  - No labels inside the arguments of higher order functions.  This 
>    will really confuse new users who try not to use labels!
>    e.g.. no "acc" in the first argument of
>       val fold_right: fun:('b -> acc:'a -> 'a) -> 'b array -> acc:'a -> 'a

But that argument doesn't really work because new users who try not
to use labels will not use label mode.


>o The "just documentation" response doesn't really hold water,
>because if the labels were just documentation, then they would
>different.  For example, "fun", being a keyword, is highly confusing
>and not terribly descriptive - any sensible prototype would probably
>just use "f".

I agree, and I would even go further.  I think the current labeling of
the standard library is way too verbose.  "fun" should not be "func"
or even "fn", but simply "f".  That's the usual name for a generic
function.  Likewise, we should replace char:char with c:char and so
on (maybe even the predicate function in List.for_all should be
labeled f).

Also, in the List module, I found this:

    val nth : 'a list -> pos:int -> 'a

This is really bad design, unless the goal is to confuse the reader
(two different names for the same number).  It should be either

    val nth : 'a list -> n:int -> 'a

or

    val posth : 'a list -> pos:int -> 'a
.

I think we need to develop a systematic set of abbreviations (and a
document to explain it) that will allow us to limit almost all labels
to be at most one character in length.  It would (at least partially)
solve the problem of expression cluttering that we have with the long
labels currently in the library.  As a side-effect, it would also
solve the problem of keywords as labels: there isn't any keyword of
length 1.


>From: Dave Mason <dmason@sarg.Ryerson.CA>
>1) please do not call it ``modern'' mode.  Call it ``label'' mode.

This is an excellent suggestion, and I have implemented it (as of
version 2.99+12) : I replaced the command-line option "-modern" with
"-label".  I kept "-modern" as an alias to "-label" for the time
being, but I certainly hope we'll retire it before we release 3.00.

-- Damien