> (b) ES6 sloppy mode cannot have "let".
>>
>
> That's overstated, and as such it contradicts the tenuous consensus of the
> last TC39 meeting: to reserve 'let' contextually in sloppy mode and
> evangelize any let [x] = y code out there already (which we've yet to find
> -- 'let' is used as an identifier, short for 'letter', but not indexed into
> on LHS).
>
> The rest of your reasoning is therefore overstated. It does not follow if
> we can reserve 'let' in ES6, mode-free.
Yes, but see below...
Here I want to refine my Platonic prettiness critique. You talk about ES6
> as if it can be a thing, which has a timeless existence and truth and
> beauty. Kind of like a dodecahedron -- a pure "Math thing".
>
It most certainly is ; )
> What I think "exists": ES6 as a practical language with a large user
> community who apprehend it in pieces, and sometimes using different
> metaphors or incomplete and even inconsistent "theories" or schools of
> thought. It's a human thing, not a Math thing.
>
It should *strive* toward truth and beauty. It should approach
Math-y-ness. The Math-y-ness is what allows us to cut through all of that
human social BS. Anyway, enough of philosophy; more practical stuff
below...
We agreed at the last meeting to treat 'let' as a contextual keyword at
> start of statement if followed by an Identifier, '{' or '['. That is a
> special case, but so what? 'module' was not reserved in ES1-5 so it needs a
> special case too.
>
Sure, but as I argued when I read about that consensus, it creates a
situation where "let" is a second-class identifier. Either it's an
identifier, or it isn't. Any middle ground is, well, sloppy! Not Math-y.
: )
> The spec must serve the users. Not the other way around. Or would you give
> up 'module' from sloppy mode?
Personally, yes. Only modules loaded by the module loader are implicitly
strict.
Imagine you are adapting existing code, including popular libraries not yet
> in strict mode, to a new app targeting ES6 or better runtimes directly, and
> ES5 and older via a compiler such as
> https://github.com/**matthewrobb/six<https://github.com/matthewrobb/six>.
> You are not yet be ready to "use strict" in the concatenation of all the
> code -- there's too much risk of breaking something, and never enough test
> coverage.
>
> You want to use ES6 features such as rest parameters and destructuring
> right away, before any "use strict" or module wrapping. Under your
> proposal, you can't. You have to multiply risks and spend time turning on
> strict mode, testing harder in old and new and middling (IE9, anyone?)
> browsers.
>
Sorry, I don't buy it.
If you have a legacy codebase, and you want to use some ES6 features
without upgrading the whole thing to strict mode, then you can selectively
upgrade the region that you are working on to strict mode by putting "use
strict" inside of a function. If that's too loose-grained, then you
shouldn't be fiddling with new features at all.
And if you're in a situation where you can't go strict, then you surely
aren't ready to depend on transcompilation.
> In 10 years, you want everyone to use modules, but there'll still be
> top-level code, rapid prototyping, and so on. For such programs, you want
> everyone to write the old
>
> "use strict";
>
In 10 years loading code via script tags will be an abandoned practice,
except for bootstrapping the module loader. Look, "use strict" is the
price that we have to pay for supporting a legacy language, in a legacy
loading context, into perpetuity. It's not going to be free. Should we
rather pay that balance by creating sloppy modes for all future ES
versions? Is this the long term vision, then?
ES3 < ES5 sloppy < ES6 sloppier < ES7 sloppiest
< ES5 strict < ES6 strict < ES7 strict
What comes after ES7 sloppiest mode? To what extent does each new sloppy
version have to drift from its strict counterpart? They cannot converge,
so divergence is the only possibility.
In this light, the least price for legacy support is to require "use
strict" in legacy contexts (e.g. script tags).
Pull off the band-aid, bite the bullet, etc. More harm is often done by
taking the slow road. And ES6, with it's substantial syntax improvements,
is the best opportunity we'll have for getting it over with.
OK - so why not make all new code-bearing bodies implicitly strict then?
Won't that buy us more strict mode usage? Well, sure, but the price is
added complexity. It sounds simple enough, but when we start digging into
the details, little problems emerge (like "let"). It's already complex
enough to support both strict and sloppy modes, why compound that
complexity by extending the reach of sloppy mode?
I think that pretty much sums up the position, and the horse may be quite
beaten at this point. What do you think?
{ Kevin }
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
