Re: Syntax for label, NEW PROPOSAL

From: John Prevost (prevost@maya.com)
Date: Wed Mar 15 2000 - 18:04:45 MET

  • Next message: Remi VANICAT: "Re: Syntax for label, NEW PROPOSAL"

    As usual, best most consistent idea is at the end. Please forgive my
    rambling.

    Pierre Weis <Pierre.Weis@inria.fr> writes:

    > The real problem is that fixing the code makes no good at all to its
    > readability (at least that's what I would say):
    >
    > # let sum l = List.fold_right fun:begin fun x acc:y -> x + y end acc:0;;
    > val sum : 'a -> int list -> int = <fun>
    >
    > It seems that, in the ``modern'' mode, application of higher order
    > functions is now denoted by a new kind of parens opening by
    > ``fun:begin fun'' and ending by ``end''. This is extremely explicit
    > but also a bit heavy (in my mind).

    Whoa. You can't just use fun:(+)?? There's a new acc label that's
    used for folds? I might have argued that fun: (or an alternative
    which isn't a reserved word, which I would support) isn't so bad to
    type. But with the labeled argument to the argument of the HOF, this
    is too much.

    As for the other semantic badness (which I actually think is syntactic
    badness to some degree) let's see what we can do:

    > -- syntactically identical patterns and expressions now may have
    > incompatible types:
    > # let f ?style:x _ = x;;
    > val f : ?style:'a -> 'b -> 'a option = <fun>
    >
    > As a pattern on the left-hand side x has type 'a, while as an
    > expression on the right hand side it has type 'a option

    I think this could be made sane by a reform of how the optional
    arguments work. There are a couple of interesting possibilities:

    # let f ?style:x _ = x;;
    - val f : ?style:('a option) -> 'b -> 'a option

    # let f (style:x : 'a option) _ = x
    - val f : style:('a option) -> 'b -> 'a option

    In the first case, the type of an optional labelled argument is always
    an option. (This makes sense in the context of what I'll say about
    arguments with default values below.)

    In the second case, any labelled argument with an option type becomes
    an optional argument. This has the disadvantage that it's impossible
    to have a required option argument. But one might argue that this
    interpretation makes sense.

    The first is dirty because there are two kinds of special arguments
    (optional and non-optional). The second because it gets into the type
    system. I think the second must lose, since "knowing" that something
    is an option type is complex.

    > -- some expressions can be only written as arguments in an application
    > context:
    > # let f ?style:x g = ?style:x;;
    > ^
    > Syntax error
    > # let f ?style:x g = g ?style:x;;
    > val f : ?style:'a -> (?style:'a -> 'b) -> 'b = <fun>

    I think you have to consider this sort of thing in the context of
    "application involves labelled arguments now" and "this syntax is part
    of application syntax and argument pattern syntax, not expressions or
    arbitrary patterns". It is a little dirty, but survivable. A syntax
    which made it more obvious what was going on might be nice. I might write:

    # let f ?style x g = ?style x
      Syntax error (label in non-application position)
    # let f ?style x g = g ?style x
    - val f : ?style 'a -> ?style ('a -> 'b) -> 'b

    Now, ?label is a special token that changes the meaning of
    application. To some degree, like methods on objects. ? would "bind"
    more closely than application, because it's sort of like an infix.
    But like #, it's more of a special effect on the following symbol.
    This is why I write:

    fooobj #method val

    instead of

    fooobj#method val

    when I use the object syntax.

    > -- the simple addition of a default value to an optional argument may
    > trigger a typechecking error:
    >
    > # let f ?(style:x) g = g ?style:x;;
    > val f : ?style:'a -> (?style:'a -> 'b) -> 'b = <fun>
    >
    > # let f ?(style:x = 1) g = g ?style:x;;
    > This expression has type int but is here used with type 'a option

    Okay. This is where my thought about changing the way this works
    comes in. From the point of view of the called function, an optional
    argument with a default value is not optional at all! From the
    outside, of course, it is. But what if we did it like this:

    # let f ?(style:x) g = g ?style:x;;
    - val f : ?style:('a option) -> ((?style:'a option) -> 'b) -> 'b = <fun>
    # let f ?(style:x = 1) g = g ?style:x;;
                        -
      This expression has type int but here is used with type 'a option
    # let f (style:x = 1) g = g ?style:x;;
                                       -
      This expression has type int but here is used with type 'a option
    # let f ?(style:x = Some 1) g = g ?style:x;;
    - val f : ?style:('a option) -> ((?style:'a option) -> 'b) -> 'b = <fun>
    # let f (style:x = Some 1) g = g ?style:x;;
    - val f : style:('a option) -> ((?style:'a option) -> 'b) -> 'b = <fun>

    What's going on here? The idea is that ? forms *always* require an
    option as their value, and the bound value is always an option. When
    you pass a value with:

    foo (?style:x)

    foo must have type:

    foo : (?style:'a option) -> 'b

    Note that I have both optional and non-optional argument syntax above
    with default values. Above, we see how changes effect local code in
    our function. (As expected, if we cause the type of the bound
    variable to change, the function breaks. Otherwise it doesn't.)

    What happens to people outside? Well, if we switch from a ? form to a
    non-? form, we're removing the implicit optionizing of the argument.
    That is:

    # let f (?style:x) = x;;
    - val f : ?style:('a option) -> 'a option

    # let f (style:x) = x;;
    - val f : style:'a -> 'a

    # let f (?style:x = Some 5) = x;;
    - val f : ?style:('a option) -> 'a option

    # let f (style:x = 5) = x;;
    - val f : ?style:int -> int

    Now, what's going on here? The ? in the type relates only to whether
    the argument is required or not. When the argument is declared with
    ?, this must be an option! When it is declared without ?, it may be
    anything.

    Come to think of it, this doesn't work either. It makes everything
    keep working as long as you keep the external type the same--but I
    just realized that telling the difference between labels that should
    be "optioned" and labels that shouldn't is hard.

    Okay. One last try.

    What if we drop back one and say that there is only one kind of
    labeled argument, written in this way (for my sake writing this):

    # let f ?style x = x;;
    - val f : ?style 'a -> 'a

    Okay. So how to optional arguments work?

    # let f ?style x () = x;;
    - val f : ?style 'a -> unit -> 'a
    # f ();;
    - : '_a option = None
    # f ?style (Some 27) ();;
    - : int option = Some 27

    What's going on here? Well--let's extend the syntax to cover default
    arguments:

    # let f (?style x = 5) () = x;;
    - val f : ?style int -> int
    # f ();;
    - : int = 5

    # let f (?style x = None) () = x;;
    - val f : ?style 'a option -> 'a option
    # f ();;
    - : '_a option = None

    and again, for reference:

    # let f (?style x) () = x;;
    - val f : ?style 'a -> 'a
    # f ();;
    - : '_a option = None

    So how is this happening--what's the interpretation?

    Oh shoot. This doesn't work either. I was going to suggest that you
    can always leave out a label, and that the default value will be
    substituted in, or if you didn't give a default, None will be
    substituted in. But that doesn't account for the top case above. One
    possibility is that it doesn't make sense to use a non-option default
    value:

    # let f (?style x = 5) () = x;;
    - val f : ?style int -> int
    * Warning: default value is not an option

    # f ();;
      f ?style None ();;
               ----
      This expression has type 'a option but is here used with type int

    # f ?style 3 ();;
    - : int = 3

    This is consistent, but sort of weird. It does certainly provide a
    fairly simple model of what optional arguments are, though. The only
    nastiness is that you need to do extra typing for each optional value
    given. I think this is a reasonable price to pay for sanity.

    # let f (?style x = Some 5) () = x;;
    - val f : ?style int option -> int option
    # let g (?style Some x = Some 5) () = x
      Warning: this pattern-matching is not exhaustive.
      Here is an example of a value that is not matched:
      None
    - val g : ?style int option -> int = <fun>
    # f ();;
    - : int option = Some 5
    # g ();;
    - : int = 5

    Of course, this is all radically different from O'Labl, so it will
    never happen.

    John.



    This archive was generated by hypermail 2b29 : Fri Mar 17 2000 - 09:11:08 MET