Re: Syntax for label, NEW PROPOSAL

[John Prevost <prevost@maya.com>]

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.