Re: Syntax for label, NEW PROPOSAL

[John Prevost <prevost@maya.com>]

Don Syme <dsyme@microsoft.com> writes:

> o To ensure "living happily together", my feeling is you should
>   leave the standard library alone (though I could live with 2 or 3
>   functions having labels), but go wild with labels and variants in
>   the places were no one doubts they will be useful.

I think I agree here.  I do see labels as useful in a number of places
(certainly places like Tk where you have large numbers of arguments,
many of which are optional.)  But, in places in the standard library,
you can create some big nasty messes.  The List.fold_right example is
a good one.  On the one hand, I do have to think about which way the
folding is going to happen, and which argument to the f argument is
which.  On the other, there are very few places where a function which
is useful for folding has an acc argument.

Arguing that a consistent labelling style is good is a nice point.  If
every function that uses an argument in a certain way has the same
label, it makes it easier to remember what's going on.  But the
functions which need labels most (those which have many arguments)
have the most specialized labels.  And the functions which are most
standard have little ambiguity, leaving reordering of arguments the
only benefit:

let foo l = map l
  fun:function
    ...
    ...
    ...

I like the ability to move the "heaviest" clause of my expression to
the end, but I'm not willing to put up with the acc thing in
fold_right to get it.  And of course, reordering is only available in
"modern" mode.

If we could come up with a semantics where labels are always optional,
I think I would accept things like acc in the standard library.  But
when you have to make a choice between optional labels and no useful
functionality, it's a harder sell.

I can imagine a system in which an unlabelled argument means "the next
argument in the argument list, regardless of label" and a labelled
argument means "the next argument in the argument list with this
label".  Of course, this leads to oddness.  Let's look at map for a
simple example:

map : f:('a -> 'b) -> 'a list -> 'b list

(I assume this hasn't changed.  I'm using f instead of fun.)

map x : 'a list -> 'b list
map f:x : 'a list -> 'b list

without a label for the 'a list, there's no way in this optional-label
scheme to re-order the argument earlier.  So this would seem to imply
that labels would only be useful if there were many different labels,
or if unlabelled arguments were "first":

map2 : 'a list -> f:('a -> 'b) -> 'b list

this option is irritating because it changes the default ordering.
And the standard ordering makes a lot more sense, even when you can
write:

map2 fun:f

to get the old behavior.

map3 : f:('a -> 'b) -> list:('a list) -> 'b list

this option preserves the standard ordering, but we had to define a
label for the second argument.  That's more okay than it would be in a
system where labels are mandatory, but it means more work for people
writing libraries using labels.  The now need to think about a
"standard" ordering for the arguments, as well as a "labelling" which
allows reordering.


Summary:

The standard library should not have labels unless labels undergo a
massive change in semantics which will remove the known-ness of
labels' utility in O'Labl.

I want labels for working with things like LablTk and LablGtk.  But
when it comes to the standard library, I agree with the SML people.
"Gross!"  I use O'Caml because it has a nicer, cleaner syntax than
SML.  Mucking it up like this, even as an optional mode, is bad.


John.