Duplicate parameters are quite common in the following case:

callSomething(function (_, _, whatIActuallyCareAbout) {});
________________________________
From: Brendan Eich<mailto:brendan at mozilla.com>
Sent: ‎12/‎29/‎2012 20:16
To: Mark S. Miller<mailto:erights at google.com>
Cc: es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>
Subject: Re: excluding features from sloppy mode

Mark S. Miller wrote:
> On Sat, Dec 29, 2012 at 1:26 PM, Brendan Eich<brendan at mozilla.com>  wrote:
>> Mark S. Miller wrote:
>>> 2) Make a micro-mode, adding yet additional mode switching in order to
>>> supposedly avoid the complexity of dealing with one mode switch.
>> No, you are using micro-mode as an epithet without actually defining it in a
>> meaningfully different way from "new semantics for new syntax".
>
> If I have a function
>
>      function foo(w, x, y) {
>        var [a, b] = y;
>        // use of a,b but not y in rest of body
>      }
>
> and I change it to
>
>      function foo(w, x, [a, b]) {
>        // use of a,b but not y in rest of body
>      }
>
> I have preserved its meaning. The change seems local to the individual
> parameter. But if I have a function
>
>      function foo(x, x, y) {

Yes, but let me interject: no one does this. It's insane. A latent bug
or a quirk that deserves an early error.

>        var [a, b] = y;
>        // use of a,b but not y in rest of body
>      }
>
> and I change it to
>
>      function foo(x, x, [a, b]) {
>        // use of a,b but not y in rest of body
>      }
>
> now my second function is rejected.

Yes, with an early error.

Since no one does duplicate formal parameter in practice, this early
error is a good thing (tm).

>   This demonstrates the
> "mode-nature" if you will of this rule.

Rather, new syntax gets new semantics.

We've shipped this for years in SpiderMonkey. I believe Rhino matches.
No one uses duplicate formals, so no one has ever complained.

>   The rejection must be
> explained by a function-wide change of what the language accepts,

No, not function-wide! Purely function-head, more specifically the
parameter list.

>   even
> though I changed only one parameter.

Parameter changes in ES6 have effects on the list. We don't allow more
than one rest parameter at the end, for example. Given

   function f(a, b, ...r) {...}

If I try adding another ellipsis:

   function f(a, ...b, ...r) {...}

I get an early error. Another good thing(tm), and no less local than
destructuring parameters banning duplicate params.

> OTOH, if destructuring is accepted only in strict code, then the
> rejection of destructuring is explained only by strictness rules.

"rejection of duplicate parameters"

Yes, that's the way to explain it via (1). And you are right that the
condition for rejection of duplicate formals becomes more than "in
strict code". It has to be "in strict mode || destructuring present in
parameter list".

However, since duplicate formals are a do-not-want, always-a-bug,
freakish rarity bestowed on ES1 during standardization, this extra
disjunct is a spec-internal complexity, not anything users must worry about.

I'm prepared to give up on the ban of duplicate formals when
destructuring parameters are present, if that will get rid of your
objection to "micro-modes". I don't recall anything else like this case.
We arrived at it mainly to simplify implementation in SpiderMonkey, but
again: users do not notice because no one uses duplicate formals.

>> Are arrow functions, syntax and definite semantics, a "micro-mode"? If not,
>> why not? I suspect you are using a mental desugaring spec but there's no
>> such spec. Allen has to deal with whether arrows have [[Construct]] (we
>> decided no, because |this| is bound to outer |this|). Is that a
>> "micro-mode"? I say no.

Did you have a thought here? It may be we're arguing only about the
"destructuring parameter bans duplicate parameters" special case.

/be
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121230/2ec971e9/attachment-0001.html>

Duplicate parameters are quite common in the following case:

    callSomething(function (_, _, whatIActuallyCareAbout) {});
________________________________
From: Brendan Eich<mailto:brendan at mozilla.com>
Sent: ?12/?29/?2012 20:16
To: Mark S. Miller<mailto:erights at google.com>
Cc: es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>
Subject: Re: excluding features from sloppy mode

Mark S. Miller wrote:
> On Sat, Dec 29, 2012 at 1:26 PM, Brendan Eich<brendan at mozilla.com>  wrote:
>> Mark S. Miller wrote:
>>> 2) Make a micro-mode, adding yet additional mode switching in order to
>>> supposedly avoid the complexity of dealing with one mode switch.
>> No, you are using micro-mode as an epithet without actually defining it in a
>> meaningfully different way from "new semantics for new syntax".
>
> If I have a function
>
>      function foo(w, x, y) {
>        var [a, b] = y;
>        // use of a,b but not y in rest of body
>      }
>
> and I change it to
>
>      function foo(w, x, [a, b]) {
>        // use of a,b but not y in rest of body
>      }
>
> I have preserved its meaning. The change seems local to the individual
> parameter. But if I have a function
>
>      function foo(x, x, y) {

Yes, but let me interject: no one does this. It's insane. A latent bug
or a quirk that deserves an early error.

>        var [a, b] = y;
>        // use of a,b but not y in rest of body
>      }
>
> and I change it to
>
>      function foo(x, x, [a, b]) {
>        // use of a,b but not y in rest of body
>      }
>
> now my second function is rejected.

Yes, with an early error.

Since no one does duplicate formal parameter in practice, this early
error is a good thing (tm).

>   This demonstrates the
> "mode-nature" if you will of this rule.

Rather, new syntax gets new semantics.

We've shipped this for years in SpiderMonkey. I believe Rhino matches.
No one uses duplicate formals, so no one has ever complained.

>   The rejection must be
> explained by a function-wide change of what the language accepts,

No, not function-wide! Purely function-head, more specifically the
parameter list.

>   even
> though I changed only one parameter.

Parameter changes in ES6 have effects on the list. We don't allow more
than one rest parameter at the end, for example. Given

   function f(a, b, ...r) {...}

If I try adding another ellipsis:

   function f(a, ...b, ...r) {...}

I get an early error. Another good thing(tm), and no less local than
destructuring parameters banning duplicate params.

> OTOH, if destructuring is accepted only in strict code, then the
> rejection of destructuring is explained only by strictness rules.

"rejection of duplicate parameters"

Yes, that's the way to explain it via (1). And you are right that the
condition for rejection of duplicate formals becomes more than "in
strict code". It has to be "in strict mode || destructuring present in
parameter list".

However, since duplicate formals are a do-not-want, always-a-bug,
freakish rarity bestowed on ES1 during standardization, this extra
disjunct is a spec-internal complexity, not anything users must worry about.

I'm prepared to give up on the ban of duplicate formals when
destructuring parameters are present, if that will get rid of your
objection to "micro-modes". I don't recall anything else like this case.
We arrived at it mainly to simplify implementation in SpiderMonkey, but
again: users do not notice because no one uses duplicate formals.

>> Are arrow functions, syntax and definite semantics, a "micro-mode"? If not,
>> why not? I suspect you are using a mental desugaring spec but there's no
>> such spec. Allen has to deal with whether arrows have [[Construct]] (we
>> decided no, because |this| is bound to outer |this|). Is that a
>> "micro-mode"? I say no.

Did you have a thought here? It may be we're arguing only about the
"destructuring parameter bans duplicate parameters" special case.

/be
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121230/2ec971e9/attachment-0001.html>