excluding features from sloppy mode

Mark S. Miller erights at google.com
Mon Dec 31 20:40:22 PST 2012


On Mon, Dec 31, 2012 at 7:49 PM, Brendan Eich <brendan at mozilla.com> wrote:
> Kevin Smith wrote:
>>
>>
>>     And again, ES5 failed to reserve 'module' in strict mode, and
>>     ES1-3 never reserved 'module', so ES6 must make 'module' only
>>     contextually reserved. We are already in "either it's an
>>     identifier, or it isn't" default. If we can do it for 'module',
>>     why not for 'let'?
>>
>>
>> Easy: "module" is still a first class identifier, but with your proposed
>> contortions, "let" is not (under sloppy mode, of course).
>
>
> No, that's not correct. We have sloppy-mode code using 'let' as an
> identifier (whatever "first class" means) today. We don't want to break it.
>
> The only place 'let' is contextually reserved in the quasi-consensus from
> the last TC39 meeting is at the start of a statement, when followed by an
> identifier, '{', or '['.
>
> Similarly, 'module' is used and usable as an identifier, but not in
> malformed syntax that ES6 proposes to define: 'module' [no LineTerminator
> here] ModuleName ... at the start of a statement.
>
>
>>         Personally, yes.  Only modules loaded by the module loader are
>>         implicitly strict.
>>
>>
>>     Now I'm confused. What about module M {...} (inline body)? What
>>     does "the module loader" mean, the system loader?
>>
>>
>> Inline modules only in strict mode, in accordance with the rule.  Only
>> out-of-line modules are implicitly strict.
>
>
> Any use-case-based rationale?
>
> Thanks for clarifying the primacy of "the rule". It was not clear, and it
> does not match what Dave proposed that Mark reconfirmed as "1JS". Although
> Dave left some wiggle room in his first post, I want to say that my attempts
> to make all new body-forms strict don't fit under the consensus "1JS" name
> and I'm not trying to usurp it. Your proposal should be called "2JS" since
> to get the new stuff, you have to "use strict".

In that case, I did not understand Dave's clarification. I thought
Dave clarified this to mean only no new additional modes or opt-ins
beyond those we already have, i.e., no mime types, additional pragmas,
etc. As I understood Dave's clarification, 1JS is orthogonal to our
decisions about how many of the new features to make available in
sloppy mode. Andreas' position (and Kevin's pre-compromise position)
is then consistent with 1JS.

Instead, what you say above seems to agree with what I thought 1JS
meant when I posted my inflammatory message. If this is what 1JS
means, then, again, I do not subscribe to 1JS.

If we cannot come to a common understanding of what 1JS means, we
should find other terminology.


>
>
>> I will bet you real (beer) money you're wrong.
>>
>> Alright - I'll take you up on that.  If in 2022 anyone is using script
>> tags for anything more than bootstrapping a module loader, I'll buy you a
>> New Year's Eve beer!
>
>
> Deal.
>
>
>>
>>     * It's an eyesore, which I think is a non-trivial objection.
>>
>>
>> Yes, but it's not required in out-of-line modules.  Which will predominate
>> quickly in new code (my prediction, yes).
>
>
> I don't think so in the browser. Concatentors will be required to minimize
> requests, which will make modules inline again.
>
>
>>
>>     * It is easy to leave out and hard to find when checking whether
>>     code in the middle of a function nest is strict.
>>
>>
>> Yes, it is easy to leave out, at least until you want to use an ES6
>> feature.  Then you get spanked : )
>
>
> Yeah, that's the thing I find turns off people at the "social BS" level. The
> Strunk&White-ian prescriptivism rings false and the kids start sassing off
> the gray-hairs. Not good for the Shire :-P.
>
>
>> I'm going to stop there.
>>
>> Brendan, I feel like I'm in a compromising mood this evening.  I can't
>> really tell whether it's because your arguments have merit or because of
>> argument by sheer exhaustion (as a previous computational theory professor
>> of mine once said)...
>
>
> We can wait till next year :-P and re-check. I'm not trying to bully anyone,
> just be a vigorous advocate (but not devil's advocate).
>
>
>> In any case, here's my compromise:
>>
>> (1) No opt-in required for new syntax, except:
>> (2) No breaking changes to sloppy mode, and
>> (3) No grammar contortions (e.g. let) to support sloppy mode.  And
>> (4) All new syntax forms with code bodies are implicit strict.
>
>
> Wow, I like!
>
> Still some friction for 'let' that will retard 'var' replacement but it's
> survivable in my muddy palantir.
>
>
>> This might seem like a complete giveaway of my previous position.
>> However, if the above four rules are adhered to, ES6 sloppy mode will be an
>> incomplete, incomprehensible jumble of features and modes.  An insane
>> language, to which the only sane response will be to hang it all and just go
>> all-strict.
>
>
> If you say so. I suggest sloppy mode will be less used with (4) strict
> bodies than in the case you formerly advocated, due to the friction caused
> by rounding up adoption cost to use-strict conversion of surrounding code
> body.
>
>> Mission f**cking accomplished.
>
>
> Let's take a breather. I am not out to force anyone into a bitter
> concession.
>
> /be
>



--
    Cheers,
    --MarkM


More information about the es-discuss mailing list