Re: Syntax for label, NEW PROPOSAL

From: John Prevost (prevost@maya.com)
Date: Fri Mar 17 2000 - 20:24:35 MET

  • Next message: David McClain: "Syntax Discussions and Caml Philosophy"

    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.



    This archive was generated by hypermail 2b29 : Sat Mar 18 2000 - 19:03:18 MET