Extend record punning to allow destructuring.

[yallop]

This patch extends the record punning syntax (b01621e) to allow simultaneous label punning and destructuring. Variables bound using as at the top level of a field pattern are treated as labels. For example, it allows you to write

   fun { { x ; y } as p; q } -> e

which is equivalent to

   fun { p = { x ; y } as p; q } -> e

[mmottl]

I like the proposal. This syntax change is non-intrusive, intuitive, and would help writing complex pattern matching rules. I sure have some code that could benefit from it.

[samoht]

Would be nice if this syntax was also able to fix cases such:

type t = { x: int; y: int }
let f { x as t } = t.y

So would be nice if we can rewrite your example to something which looks like:

fun { { x ; y as p } ; q } -> e

[hcarty]

I have wanted this or something similar in the past when using nested records. If you change as p to as not_a_field_name would you still get Error: Unbound record field not_a_field_name with proper location information?

[pw374]

On 30 Jan 2014, at 14:14 pm, Thomas Gazagnaire notifications@github.com wrote:

Would be nice if this syntax was also able to fix cases such:

type t = { x: int; y: int }
let f { x as t } = t.y
So would be nice if we can rewrite your example to something which looks like:

fun { { x ; y as p } ; q } -> e

I can see that it saves a few characters but it’s not worth it in my opinion.
This syntax feels very odd, because in { x as t } it’s not x that’s as t, but the entire record.
I don’t like it, to me it’s somewhat misleading and unnatural.

[yallop]

@hcarty: yes, location information and error messages are preserved.

# fun { { x ; y } as not_a_field_name; q } -> ();;
Characters 19-35:
  fun { { x ; y } as not_a_field_name; q } -> ();;
                     ^^^^^^^^^^^^^^^^
Error: Unbound record field not_a_field_name

[mmottl]

@samoht: not bad, but you'd only save having to type an extra pair of parentheses then. The "as" syntax as such already saves you having to duplicate a (potentially long) field name. The "x as t" looks a little strange to me. I think I'd prefer having the binding outside of the enclosing structure as in the first proposal.

[samoht]

Regarding my proposition, it's exactly the same as for tuples (which already works):

let f (x, _ as t) = snd t

[mmottl]

@samoht: true, but that's because the tuple syntax, unlike records, allows you to drop parentheses in the first place. The enclosing parentheses here aren't required by the tuple, only by the "as"-binding.

Update: to be precise, the tuple does require the parentheses here, because it's a function definition, but not e.g. in:

let x, _ as t = ...

[pw374]

@samoht wrote:

Regarding my proposition, it's exactly the same as for tuples (which already works):

let f (x, _ as t) = snd t

But that’s between parenthesis, not curly braces.
The “as” takes "everything" on its left side, no matter if it’s a tuple or an or-pattern
(as in

# let f = function (`A | `B (_, _) as t) -> t;;
val f : [< `A | `B of 'a * 'b ] -> [> `A | `B of 'a * 'b ] = <fun>

the "as t" takes everything of its left)

[samoht]

But that’s between parenthesis, not curly braces.

I'm just proposing to have a consistent notation for tuple and records. But I see your point, so I stop arguing :-)

[pw374]

I believe I’ve found a better and stronger reason:
in
function { contents = (A | B) as x } -> x
is it the whole record that is as x, or just the value of the field contents? ;-)

[alainfrisch]

Another useful extension of the syntax for record patterns would be:

{ x.a = pa; x.b = pb; x.c; y.t = pt }

equivalent to:

{ x = {a = pa; b = pb; c}; y = {t = pt} };

This would also be useful for record override:

{ r with x.a = ea; x.b = eb; x.c; y.t = et }

equivalent to:

{r with x = {r.x with a = ea; b = eb; c}; y = {r.y with t = et}}

[Kakadu]

I'm on @pw374 's side. I don't like

type t = { x: int; y: int }
let f { x as t } = t.y 

It will be great if 2nd line will be parsed as equivalent to let f {y; x as t } = y (t should be a filed of record, not the whole record). Probably idea this change is inspired by camlp4r but I still don't like. If we apply it line let f { y; x as t } = t.y will look strange for me.

[gasche]

If I can indulge in a small meta note, I think community review works best for proposal that have a good chance of being consensual. As soon as something touches the language definition, the design space explodes and it's very hard to reach agreement (whether in small or larger groups) -- it's one of the reason why maintainers are generally so reluctant with syntax changes. While I don't think Jeremy's initial suggestion was unreasonable, I'll personally prudently avoid trying to obtain an actual decision on this, at least for now.

[pw374]

On 31 Jan 2014, at 16:50, @gasche wrote:

If I can indulge in a small meta note, I think community review works best for proposal that have a good chance of being consensual. As soon as something touches the language definition, the design space explodes and it's very hard to reach agreement (whether in small or larger groups) -- it's one of the reason why maintainers are generally so reluctant with syntax changes. While I don't think Jeremy's initial suggestion was unreasonable, I'll personally prudently avoid trying to obtain an actual decision on this, at least for now.

I do like @yallop's initial suggestion. I believe no one on this thread has shown to be against it.

It’s a tiny patch (only 2 reasonable new lines in parsing/parser.mly) and it doesn’t seem to introduce any ambiguity on the syntax.

[mmottl]

Let me add some support for the first proposal, too. I think it at least deserves a short discussion.

[garrigue]

I kind of wonder whether this change (the initial proposal) is worthwhile.
Namely, in { { x ; y } as p; q } it is not very intuitive that p is a field name.
Wouldn't it end up obfuscating the code, for a very small change in the number of characters?
This is just a consequence of the fact the alias comes after the aliased pattern in ML, which was probably not a good idea to start with, but we're stuck with that.

[gasche]

@garrigue : couldn't we fix this by interpreting as as symmetrical pattern intersection, allowing <pattern> as <simple pattern>, or at least an additional <variable> as <simple pattern>?

[damiendoligez]

@gasche I've always wanted to write x as <pattern> instead of <pattern> as x, so this addition would feel very natural to me. Now adding it to the grammar, that's another can of worms...

[gasche]

We discussed this PR at the developer meeting yesterday, and there was opposition (not from me) to including it without a patch allowing to write at least x as <pattern> (or possibly p1 as p2 for general intersection) to use a more natural order.

(We have no guarantees, of course, that a proposal including this richer syntax would be accepted. I would personally support¹ p1 as p2 independently of the present change.)

¹: another thing I would like to have is for the individual patterns in p1 | p2 have variables that do not appear in the other pattern (but only allow to use variables from the intersection in the right-hand-side). Possibly we could restrict this to variables prefixed with _. The idea is that naming things can clarify, even when they are unused.

[yallop]

Thanks for the feedback. I'll investigate supporting the more general syntax.

another think I would like to have is for the individual patterns in p1 | p2 have variables that do not appear in the other pattern (but only allow to use variables from the intersection in the right-hand-side).

I'd like to have that as well. The old patterns Camlp4 extension used to support that behaviour, IIRC. Even more ambitiously, it'd be good to have something similar for GADTs, if they're ever updated to support |-patterns -- i.e. to have p1 | p2 to introduce the constraints that are in the intersection. (However, both these extensions are beyond the scope of this PR, which has already grown rather significantly.)