On Fri, Aug 16, 2013 at 11:26 AM, Kevin Smith <zenparsing at gmail.com> wrote:

>
>> And for the strict match one could introduce match(...) function which
>> already would throw providing exactly matching procedure first, and then
>> destructuring as a consequence.
>>
>
> Do you not think that it would be awkward to have the exact same pattern
> syntax for these two cases (matching and destructuring), but with different
> semantics?
>
>

Yes, I don't think so. Also, this exact (or strict, or refutable if you
will) matching I'm proposing as addition. And for this it's good to have a
very good practical use-case and a reason. Do you know such practical
use-cases today when people need strict match with throwing? How widely
they are used?

tl;dr:

In immutable state languages, there is no assignment operation, there is
only "binding-and-matching" operation. Which means an unbound variable can
be bound once, and all other "assignment" operations already pattern
matching operations -- they can only check whether the LHS matches to what
is on RHS.

X = 10; // initial binding

X = 20; // throw, doesn't match
X = 10; // OK, match

Y = 10;
X = Y; // OK, match

Z = [1, 2, 3];
Z = [1, 2, 3]; // OK, match
[A, B, C] = Z; // OK, match. See -- the matching goes first, and the
destructuring is just a consequence.
[A, _, C] = Z; // OK, match, skipping second element
[A, B] = Z; // throw, doesn't match

In JS, there is mutation and assignment. And pattern matching here is
secondary. Initially exactly the destructuring plays main role here. And
again, for the current foo.nonExisting being undefined use-case is also
leans towards not throwing.

The non-strict destructuring use-case is though can be wide spread,
especially with `config` parameters:

function init({ip, coords: [x, y]}) { ... }

The match function can go either on RHS (which probably better, but I'm not
sure at implementation), or LHS:

switch (match(foo)) {
  case {x, y}:
  case [a,b ,c]
}

The match(...) function may just set [[StrictMatch]] temp prop on the
object and then matching goes with the strict (I wouldn't do it using "use
strict;" though). But don't wanna go deeply to bike-sheading about it.

Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130816/f9c7f31e/attachment.html>

On Fri, Aug 16, 2013 at 11:26 AM, Kevin Smith <zenparsing at gmail.com> wrote:

> Do you not think that it would be awkward to have the exact same pattern
> syntax for these two cases (matching and destructuring), but with different
> semantics?

Yes, I don't think so. Also, this exact (or strict, or refutable if you
will) matching I'm proposing as addition. And for this it's good to have a
very good practical use-case and a reason. Do you know such practical
use-cases today when people need strict match with throwing? How widely
they are used?

tl;dr:

In immutable state languages, there is no assignment operation, there is
only "binding-and-matching" operation. Which means an unbound variable can
be bound once, and all other "assignment" operations already pattern
matching operations -- they can only check whether the LHS matches to what
is on RHS.

```js
X = 10; // initial binding

X = 20; // throw, doesn't match
X = 10; // OK, match

Y = 10;
X = Y; // OK, match

Z = [1, 2, 3];
Z = [1, 2, 3]; // OK, match
[A, B, C] = Z; // OK, match. See -- the matching goes first, and the
destructuring is just a consequence.
[A, _, C] = Z; // OK, match, skipping second element
[A, B] = Z; // throw, doesn't match
```

In JS, there is mutation and assignment. And pattern matching here is
secondary. Initially exactly the destructuring plays main role here. And
again, for the current foo.nonExisting being undefined use-case is also
leans towards not throwing.

The non-strict destructuring use-case is though can be wide spread,
especially with `config` parameters:

```js
function init({ip, coords: [x, y]}) { ... }
```

The match function can go either on RHS (which probably better, but I'm not
sure at implementation), or LHS:

```js
switch (match(foo)) {
  case {x, y}:
  case [a,b ,c]
}
```

The match(...) function may just set [[StrictMatch]] temp prop on the
object and then matching goes with the strict (I wouldn't do it using "use
strict;" though). But don't wanna go deeply to bike-sheading about it.