It's es-discuss, don't be scared. Just working through a thought-experiment, however misguided in someone's view, is low-cost and needs a forum for discussion. Occasionally we are all mistaken about an idea being misguided, and the experiment will prove worth the cost of discussion.
Yes. We need to talk about what actually has happened on the web with opt-in attributes and modifiers, though -- not just try to build a minimized logic system that we think is convenient (mostly because it is minimized).
Just to be clear, the RFC4329 version parameter was never proposed as sufficient. It or something equivalent in the script type attribute is necessary on the web to hide new script from old browsers.
This is a job for ES6 itself, not just its opt-in system.
Taken one way, this excludes new semantics, since people have to build everything today using objects and closures. Making a virtue of necessity could kill almost any proposal (destructuring, generators, modules -- even let). It's not clear how listing several variables to minimize helps if we don't have a trade-off formula against opportunity costs and cost of building everything more or less in today's style.
Five fingers of fate. Only one used right now.
Amen -- this is the impetus for the "scary" discussion.
The Harmony page talks about doing this by desugaring where possible, extending kernel semantics only where necessary and with primitives that compose well. This implies that a new, consolidated Harmony-era spec must define how extended semantics interact with strict semantics at least. But we may have assumed that we didn't need to define interactions with non-strict semantics. That raises the question of opt-in before us. My point is that *if* opt-in usability demands defining extended vs. non-strict complications, then so be it. We should take the hit. Again minimizing all of 4 or 7 variables is impossible. There are trade-offs. Judging them well is an art and it does depend on usability in the large (your goals 1 and 6 may well trump 7).
We've considered marginally breaking changes, e.g. completion reform. We should discuss this one more if necessary.
Agree that 1 vs. 6 is the fight to focus on here.
You made some good points already in the thread against this, phrased in terms of those strict-vs.non-strict semantic shifts (eval of var, arguments aliasing, a few others -- not terribly many). I'm happy to concede (I thought I did already) that was a mortal blow to "tainting" implicit opt-in where a Harmony feature at the last line of 60,000 would put the whole large program in strict mode. Let's agree on this if we can (Allen may not).
That is a loaded verb-form ("backporting"). Who says there is a separate older spec or implementation to which to port? Yes, analyzing interactions requires reading the ES5 spec in non-strict mode. No, the result is not necessarily a port -- it's a patch (if you insist on hacking metaphors).
I object. 3 is misstated to assume "switching" means all-or-nothing. If ES6 has new features and they are worth using, developers will want to use them piecewise and conveniently. Assuming they will do so at the price of a leading "use version 6" or equivalent pragma is debatable. We shouldn't just assume this conclusion. I think 3 should be stated as "Provide as many incentives for using ES6 as possible". Here "using" does not demote making use of every last feature in every script. There's no need to require "switching" and it may be user-hostile to do so.
This does not follow. Users transitioning to use new features may be helped, not hindered, by we spec and implementation editors working harder. In particular allowing, e.g., destructuring in non-strict code may be boon to developers, whereas requiring them to maintain explicit opt-in pragmas before doing so simply to convenience spec editors and implementors may be a global loss. The game theory is multi-party and the moral hazard for us as spec and implementation people is to optimize for our own convenience or assert that it's identical to developer usability. It's not.
Let's agree, based on your earlier arguments and also on Dave's point that lexical scope (free variable error analysis) won't work if opt-in is too local. This still does not mean that all extensions must be supported only under all-or-nothing early opt-in.
You are arguing based on "simplest" without considering real-world usability. Too much a-priori system building makes a crashed sky castle, I've seen this over and over. On the web, a-posteriori wins. On the web, people lose version opt-in pragmas and MIME type versions (Larry Masinter made this point about the latter but it applies to the former). On the web, we have "use strict"; in the middle of concatenations. We have Unicode BOMs in the middle. We have <!-- hide script from old browsers and // --> and even --> in the middle of .js files! No plan survives contact with the enemy (Moltke) comes to mind. Meanwhile, JS1 grew via ES1-5 and various implementations (SpiderMonkey and Rhino) without any such opt-in, *except* for two keywords we couldn't reserve (and some incompatible change attempts that failed, vs. goal 8 -- one example: I tried to make == and != strict in JS1.2 to get ES1 to switch, but that broke the web, wherefore === and !==).
I'm sure it wins for spec authors and implementors -- forking large parts of the spec might even "win" in the short term. These would all be bad for users, IMHO.
So I'd have to write use version 6; module {...} instead of just module {...} even though there's no backward compatibility issue? That's just mean! :-|
Why first if (as Dave's proposal in its minimal form did) a later module cannot affect earlier non-strict top level semantics? Again there is no backward compatibility issue. Why, as spec writer or implementor, do you care whether it's <script> // non-strict top level code </script> <script> module {...} </script> or the concatenation? <script> // non-strict top level code module {...} </script> Nothing in the spec or an optimizing implementation, if we assume module M is its own opt-in such that ... is in ES6, should care when processing the non-strict top level code.
First lines get lost or moved down all the time. Making this an early error helps only assuming diligent testing in new implementations. That's not safe to assume.
Yeah, it's ok -- but let's not keep cleaning the slate. We have RFC4329 and browsers do hide new version= values. We have a proposal lurking about for "use version 6". Avoiding bikeshedding is one thing, avoiding usability testing and assuming the first-line selector wins is not justified.
Another assumption. There may be more carrots this time, but if the explicit opt-in requirement is too unusable in practice, then ES6 may bounce, or simply have slower adoption that we'd like, ceteris paribus (many variables here, hard to project -- let's avoid arguing based on our favored speculations). My non-speculative argument rests on experience on the web. Version marks and other separators are mangled and lost all the time. I believe we should offer well-defined <script type=...;version=...> opt-in for script content hiding from old UAs, and *in addition* belt-and-braces in-script-content version opt-in at a minimum, via some pragma such as |use version 6;|. But I also believe these will be lost or simply not used, and adoption will be better if we define sensible (per your arguments against tainting from small to large extent) new-syntax-is-its-own-opt-in rules, per Dave's o.p. The reason I believe this is our experience in past edition shifts and experimental extensions. Usability wins should tax spec-editors (if not implementors -- let's not assume the implementation costs of implicit opt-in are too high [*]) for the greater good of the JS developers. /be [*] SpiderMonkey has no runtime tests based on <script type="...; version=X"> values, if I'm not mistaken, and very few compile-time. And this is with quite a few extensions, including standard ones such as E4X. Yes, we learned some lessons at non-trivial cost, but these need not be re-learned from scratch by TC39. |
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
