On Mon, Dec 31, 2012 at 7:49 PM, Brendan Eich <bren...@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
