Discuss
  • Comments on Refutable Patterns proposal

Comments on Refutable Patterns proposal

# Axel Rauschmayer (13 years ago)

harmony:refutable_matching

  • Would love to see examples for arrays. Especially if there are more element patterns (lhs) than array elements (rhs).

  • Possible future extensions: Make pattern after "..." optional, allow "..." in the middle of an array. Examples: let [...front, last] = someArray; let [..., last] = someArray; let [first, ...] = someArray;

  • Missing parameter in third-last line? Match(ElementPatterns, value, index, soft) = assert IsObject(value) case ElementPatterns of ElementPattern => Match(ElementPattern, value, index, soft) ElementPattern "," ElementPatterns => if Match(ElementPattern, value, index, soft) = SUCCESS then Match(ElementPatterns, value, soft) (* Missing? index+1 *) else FAILURE

# Andreas Rossberg (12 years ago)

On 21 March 2013 00:04, Axel Rauschmayer <axel at rauschma.de> wrote:

harmony:refutable_matching

  • Would love to see examples for arrays. Especially if there are more element patterns (lhs) than array elements (rhs).

Good point. I added some.

  • Possible future extensions: Make pattern after "..." optional, allow "..." in the middle of an array. Examples: let [...front, last] = someArray; let [..., last] = someArray; let [first, ...] = someArray;

Yeah, rest patterns in other places were already decided out of scope for ES6 a while ago. And I did not include them here either because it is far from clear what a reasonable semantics should be for all kinds of corner cases. Just consider:

let [a, b, c, ...middle, x, y, z] = {'0': 0, '4': 4, length: 3}

And with rest patterns at the end only, I don't think you'd ever want to write "..." without a subpattern. The only difference between [x, y] and [x, y, ...] would be that the latter (somewhat redundantly) checks the presence of a length property.

  • Missing parameter in third-last line?

Match(ElementPatterns, value, index, soft) = assert IsObject(value) case ElementPatterns of ElementPattern => Match(ElementPattern, value, index, soft) ElementPattern "," ElementPatterns => if Match(ElementPattern, value, index, soft) = SUCCESS then Match(ElementPatterns, value, soft) (* Missing? index+1 *) else FAILURE

Oops, you're right. Fixed that and two other things regarding array patterns.

Thanks for the comments.

# Axel Rauschmayer (12 years ago)

Yeah, rest patterns in other places were already decided out of scope for ES6 a while ago. And I did not include them here either because it is far from clear what a reasonable semantics should be for all kinds of corner cases. Just consider:

let [a, b, c, ...middle, x, y, z] = {'0': 0, '4': 4, length: 3}

I completely agree with them being tricky. But it might make sense to record that they have been considered and explicitly excluded from ES6.

And with rest patterns at the end only, I don't think you'd ever want to write "..." without a subpattern. The only difference between [x, y] and [x, y, ...] would be that the latter (somewhat redundantly) checks the presence of a length property.

Ah! I would expect [x,y] to only match arrays whose length is 2. Is there a benefit to being more lenient?

Axel

# Brandon Benvie (12 years ago)

On 3/21/2013 10:14 AM, Axel Rauschmayer wrote:

And with rest patterns at the end only, I don't think you'd ever want to write "..." without a subpattern. The only difference between [x, y] and [x, y, ...] would be that the latter (somewhat redundantly) checks the presence of a length property.

Ah! I would expect [x,y] to only match arrays whose length is 2. Is there a benefit to being more lenient?

I wouldn't expect that at all, for the same reason I would expect let { x, y } = { x: 1, y: 2, z: 3 } to work.

# Tab Atkins Jr. (12 years ago)

On Thu, Mar 21, 2013 at 10:51 AM, Brandon Benvie <bbenvie at mozilla.com> wrote:

On 3/21/2013 10:14 AM, Axel Rauschmayer wrote:

And with rest patterns at the end only, I don't think you'd ever want to write "..." without a subpattern. The only difference between [x, y] and [x, y, ...] would be that the latter (somewhat redundantly) checks the presence of a length property.

Ah! I would expect [x,y] to only match arrays whose length is 2. Is there a benefit to being more lenient?

I wouldn't expect that at all, for the same reason I would expect let { x, y } = { x: 1, y: 2, z: 3 } to work.

And in Python, for example, I often get annoyed when the interpreter reminds me that the length of an unpacked tuple must be the same as the originating tuple, even if I'm intentionally ignoring the end of it.

# Axel Rauschmayer (12 years ago)

Ah! I would expect [x,y] to only match arrays whose length is 2. Is there a benefit to being more lenient? I wouldn't expect that at all, for the same reason I would expect let { x, y } = { x: 1, y: 2, z: 3 } to work.

I’m influenced by Prolog that has [x,y] and [x,y | rest]. Matching by position feels different to me than matching by key, but I see your point. It is also consistent with how function parameters are handled.

# Brandon Benvie (12 years ago)

On 3/21/2013 10:54 AM, Tab Atkins Jr. wrote:

On Thu, Mar 21, 2013 at 10:51 AM, Brandon Benvie <bbenvie at mozilla.com> wrote:

On 3/21/2013 10:14 AM, Axel Rauschmayer wrote:

And with rest patterns at the end only, I don't think you'd ever want to write "..." without a subpattern. The only difference between [x, y] and [x, y, ...] would be that the latter (somewhat redundantly) checks the presence of a length property. Ah! I would expect [x,y] to only match arrays whose length is 2. Is there a benefit to being more lenient? I wouldn't expect that at all, for the same reason I would expect let { x, y } = { x: 1, y: 2, z: 3 } to work. And in Python, for example, I often get annoyed when the interpreter reminds me that the length of an unpacked tuple must be the same as the originating tuple, even if I'm intentionally ignoring the end of it.

~TJ

This also. I think a common use case is to grab the items at the beginning of a variable (or even unknown) length array. I also don't see the benefit of requiring exact length matching, especially when it would require adding additional syntax to bring back the ability to work with variable/unknown length arrays.

# Brendan Eich (12 years ago)

Brandon Benvie wrote:

On 3/21/2013 10:54 AM, Tab Atkins Jr. wrote:

On Thu, Mar 21, 2013 at 10:51 AM, Brandon Benvie <bbenvie at mozilla.com> wrote:

On 3/21/2013 10:14 AM, Axel Rauschmayer wrote:

And with rest patterns at the end only, I don't think you'd ever want to write "..." without a subpattern. The only difference between [x, y] and [x, y, ...] would be that the latter (somewhat redundantly) checks the presence of a length property. Ah! I would expect [x,y] to only match arrays whose length is 2. Is there a benefit to being more lenient? I wouldn't expect that at all, for the same reason I would expect let { x, y } = { x: 1, y: 2, z: 3 } to work. And in Python, for example, I often get annoyed when the interpreter reminds me that the length of an unpacked tuple must be the same as the originating tuple, even if I'm intentionally ignoring the end of it.

~TJ This also. I think a common use case is to grab the items at the beginning of a variable (or even unknown) length array. I also don't see the benefit of requiring exact length matching, especially when it would require adding additional syntax to bring back the ability to work with variable/unknown length arrays.

We have talked of literals in the pattern language:

let {0:x, 1:y, length:2} = pair_only_please();

It's a pain to write an object pattern instead of an array, but this is the exception to the rule, or would be were it supported. And it may be in the future.