excluding features from sloppy mode

Mark S. Miller erights at google.com
Sat Dec 29 13:35:01 PST 2012


On Sat, Dec 29, 2012 at 1:26 PM, Brendan Eich <brendan at mozilla.com> wrote:
> Mark S. Miller wrote:
>>
>> On Sat, Dec 29, 2012 at 1:06 PM, Brendan Eich<brendan at mozilla.com>  wrote:
>>>
>>> Who ever proposed that? It seems a misunderstanding. No one is saying
>>> that,
>>>
>>> e.g., destructuring formal parameters, or a rest parameter, should flip
>>> the
>>> containing function into strict mode. Banning duplicate formals in no
>>> wise
>>> does that.
>>
>>
>> This is an example of the micro-modes issue. If optional, rest, and/or
>> destructuring needs to enforce no duplicates, then we have two
>> choices:
>>
>> 1) Make these features available only in strict code, which doesn't
>> require any new special case -- since strict already bans duplicate
>> parameter names.
>
>
> Agree so far.
>
>
>> 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) {
      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. This demonstrates the
"mode-nature" if you will of this rule. The rejection must be
explained by a function-wide change of what the language accepts, even
though I changed only one parameter.

OTOH, if destructuring is accepted only in strict code, then the
rejection of destructuring is explained only by strictness rules. In
strict code, the rejection of duplicate parameters is explained only
by strictness rules, and applies to both functions above. No
micro-modes in sight.


>
> 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.
>
>
>> By our previous criteria, #1 is obviously simpler than #2.
>
>
> I dispute that. The complexity to count is user-facing, not spec-internal or
> mental-desugaring or other invisible complexity. Users need to know about
> arrows when writing them. When calling, not so much (one cannot assume all
> functions are constructors, even in ES1 [builtins]).
>
> Let's try to get to an apples-to-apples user-facing complexity metric, and
> leave the stuff under the spec hood out.
>
> /be



--
    Cheers,
    --MarkM


More information about the es-discuss mailing list