excluding features from sloppy mode

Brendan Eich brendan at mozilla.com
Sat Dec 29 13:26:47 PST 2012


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".

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


More information about the es-discuss mailing list