On Thu, Oct 14, 2010 at 8:29 AM, Brendan Eich <bren...@mozilla.com> wrote:
> On Oct 14, 2010, at 8:12 AM, Mark S. Miller wrote: > > > On Wed, Oct 13, 2010 at 5:35 PM, Brendan Eich <bren...@mozilla.com> > wrote: > > On Oct 13, 2010, at 4:31 PM, Mark S. Miller wrote: > > > >> Recently, I met with the Google V8 team for two full days. One message > that came through loud and clear, that I said I would relay to the list, is > "please, no more modes." > > > > If this is an attempt to avoid <script type="harmony"> (harmony a > placeholder for something more RFC4329-conformant), it's not going to work. > > > > Declaring what the conclusions of discussions must be is not helpful. I > am raising an issue. Let's discuss it. > > The shoe seems to be on the other foot, to be blunt. You knew about > http://wiki.ecmascript.org/doku.php?id=strawman:versioning and previous > work -- did you raise the issue? It seems you met for two days with V8 folks > and came back with "no more modes", ignoring the work we'd done in TC39 on > exactly why opt-in versioning seems required, and how it might work. That is > less than helpful. > > Sorry for being grumpy, Apology will be accepted once you stop being so grumpy ;). I really am surprised by your tone here. I did not raise this issue before because I do not feel strongly about this issue. I also had never had a multi-day meeting with the V8 folks before. In the previous meetings and conversations we've had, they never communicated this objection to me. During that recent two day meeting, they did convey this objection, emphatically. This was new information for me. Now it is new information for you. Can we please calm down now? > but wishing away modes or versioning won't cut it, here or for WebSockets > or other new stuff. The Web has not always evolved backward-compatibly, nor > can it always -- nor should it, since old forms die off and new forms are > needed to prevent stagnation -- wherefore ES5 and its incompatible changes, > just like ES3, ES2, and JS itself before them. > > Wishing, assuming, or stipulating that the Web must stop changing > incompatible under opt-in versioning therefore simply begs the question of > why things are different this time. Assuming we can be modeless when we're > adding new syntax contradicts 15 years of direct experience. It's true we > had a "versionless" era since ES3 was finalized, sort of: you have to ignore > all the > > if (document.all { > // IE code here, no getters/setters, no Array extras > } else { > // for the last four years or more, getters/setters, etc. > } > > versioning code. > > Versioning happens. Object detection, a la document.all testing (or better, > this.JSON testing in global code) is arguably best, although not without > pitfalls. > > The worst thing we could do is force developers to user-agent sniff. But > that seems where "no more modes" is headed, because content authors cannot > afford to send syntax errors with no fallback automation to downrev > browsers. > > > > Given <script type="harmony"> as an opt-in, I'm puzzled about how it > would work anyway. Since it is per script, not per frame, presumably > > > > <script type="harmony">"use strict"; var e1 = eval;</script> > > <script>"use strict"; var e2 = eval;</script> > > <script ...>"use strict"; e1 === e2 /*results in true*/ </script> > > > > In other words, that both harmony and non harmony code on the same page > have the same binding for the global "eval" function. In that case, what > does the following code do: > > > > e2(' "use strict"; var module = 8;'); > > > > This is currently legal es5/strict code. As suggested by the modules > strawman, it is not legal harmony code. es5/strict and harmony share a heap. > I do not see a good answer. > > First, whatever the answer here, the overriding motivation for opt-in > versioning remains. You can solve this a number of ways. The front-runner, > which came out at the last TC39 meeting and was a surprise to me, is to make > all Harmony scripts use lexical scope, not the global object. Doing so > avoids this problem by making e1 not visible to non-Harmony scripts, because > it is not a property of the global object. > > Of course e2 would be a global property, so the question remains: if > Harmony script can get at the global object, it can invoke e2 as an indirect > eval. But the answer then to the question "what version is this indirect > eval using to compile with?" must be pre-Harmony. > > Indeed, we implemented this when we added 'let' and 'yield' keywords under > opt-in versioning in JS1.7. ES5 strict reserves these under the "use strict" > opt in. From ES5 10.1.1: > > * Eval code is strict eval code if it begins with a Directive Prologue that > contains a Use Strict Directive or if the call to eval is a direct call (see > 15.1.2.1.1) to the eval function that is contained in strict mode code. > > Thus there is already one bit of opt-in versioning state in ES5, which must > be carried from direct eval's caller to callee. But indirect eval is > non-strict without a "use strict"; in the eval'ed source string. > > This strongly suggests doing the same for another bit of opt-in versioning, > to the Harmony version. > > Again, this is all a sideshow to the main issues I (re-)raised. It needs to > be resolved but it does not remove the overriding reason for opt-in > versioning: new syntax and semantics (lexical global scope), not merely new > keywords. I'd like to hear those addressed. > > /be -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
