Re: ES6 doesn't need opt-in
On Jan 8, 2012, at 8:05 , Brendan Eich wrote: > Allen has 5&6, ES5, ES6, and Compat5. Relabel these to > > ES5-nonstrict-ES6-intersection > ES5-nonstrict > ES6 > ES5-nonstrict-differs-from-ES6 > > Since ES5-strict is a subset of ES6, it doesn't require new states. I like these labels! Isn’t ES5.nonstrict the union of ES5.nonstrict-ES6-intersection and ES5.nonstrict-differs-from-ES6? If yes then ES5.nonstrict disappears and we might have a venn diagram intersecting ES5.nonstrict and ES6: ES5.nonstrict-only (=ES5.nonstrict-differs-from-ES6) ES5.nonstrict-ES6-intersection ES6-only (=ES6-differs-from-ES5.nonstrict) This might be about to the question as to whether there should be a mode that combines ES6-differs-from-ES5.strict constructs with ES5.nonstrict. I don’t think there should be. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 7, 2012, at 9:35 PM, Gavin Barraclough wrote: > On Jan 7, 2012, at 8:39 PM, Brendan Eich wrote: >> Remember, we are not proposing breaking semantic shifts of meaning for >> existing syntax. So the realistic worry is that you have code with >> arguments[i] aliasing a formal, and this is required for correct operation, >> and you then start using ES6 features (which imply ES5-strict), which breaks >> arguments aliasing. > > Hmmm, I was thinking this proposal implied much more of a breaking change > (e.g. removing the global object from scope), Nope, as dherman's o.p. said: "giving up". But not the free variable analysis based on implicitly imported global object properties, for early errors on typos, of course. > but if the change in semantics largely comes down to enabling ES5-strict then > maybe this isn't so bad. If we are talking about implicitly enabling > ES5-strict for the whole program, I would think there may be a quite a few > more hazards to consider? (code that implicitly introduces variables onto the > global object, assumes this conversion to global object value in function > calls, uses callee/caller/arguments, etc). See Allen's state machine. It requires state transitions for the syntax whose meaning shifted from ES5 (non-strict, as Mark points out this is only part of ES5 so a misnamed label) to ES6. > Still, I'm warming up to the idea considerably if the implicit opt-in is > triggering no major breaking changes. The state machine won't trigger breaking runtime shifts but it will make early errors out of inconsistent combinations of ES5-nonstrict and ES6 features in a single program. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 7, 2012, at 11:05 PM, Brendan Eich wrote: > Allen has 5&6, ES5, ES6, and Compat5. Relabel these to > > ES5-nonstrict-ES6-intersection > ES5-nonstrict > ES6 > ES5-nonstrict-differs-from-ES6 > > Since ES5-strict is a subset of ES6, it doesn't require new states. Again we wink at completion reform -- it changes semantics such that ES5-strict is not a subset of ES6 but we believe no code will notice (we could be wrong). We give up on typeof null and removing the global object. The free variable analysis based on global properties still gives early error on typo wins. That makes the subset relation technically false too but let's also wink at it by considering only strict programs that reach runtime under either an ES5 or an ES6 implementation. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 6, 2012, at 7:48 PM, Mark S. Miller wrote: > > > Then I would only expect two labels: ES6 and non-strict > > You're counting different beans from Mark's "modes" and from Allen's states. > > Hi Brendan, as I read it, Axel captures exactly the two modes I have in mind. Ok, good to have fewer positions :-). > The reason the state machine matters is implementation (including the fine > spec, the normative implementation). Authors can think of writing non-strict > ES5 or lower, or ES5 strict -- or ES6 if they use a bit of novelty. Different > beans again. > > I'm not sure what informs your label count expectation. In writing JS for the > web over the next several years, you might have to worry quite a bit about > ES5 strict vs. ES6. You can't just assume ES6 works everywhere that ES5 > strict works. > > The issue is: What does it mean for a browser to be standards compliant once > it is fully conformant with ES6? Yes, of course there will be a long phase of > partial ES6 compliance as features are incrementally rolled out. Just as > there was with ES5. Still is. > But during this period, no one claims full conformance with ES6, so standards > compliance mean only compliance with ES5. To be standards compliant once one > is ES6 compliant, the state machine + ES6 keeps some portion of the ES5 spec > as a live normative spec because it is reachable from the state machine. The > only question is: Which portion is reachable? With Allen's plan, all of it. > With the one line revision Axel and I have in mind, the ES5-strict spec stops > being reachable as normative for ES6 compliant browsers. It is dead code that > can be considered garbage. Your post two above the one to which I'm replying proposes to have only ES5 non-strict and ES6, with "use strict"; (the string literal directive) enabling ES6. I don't a difference except in state-machine labels with what Allen proposes. Allen has 5&6, ES5, ES6, and Compat5. Relabel these to ES5-nonstrict-ES6-intersection ES5-nonstrict ES6 ES5-nonstrict-differs-from-ES6 Since ES5-strict is a subset of ES6, it doesn't require new states. Function declarations in blocks and (depending on implementation) const extensions fall into ES5-nonstrict-differs-from-ES6 as noted. That is, "ES5-nonstrict" must be read to include an implementations extensions that pre-date ES5, that are enabled without "use strict";, and of course which conflict with ES5 strict. You previously wrote: > For example, since legacy constrains us from making nested named function > declarations a triggering feature, if program #2 [one with "use strict"; and > conforming to ES5 strict] has a nested named function and the browser > rejected it, that browser would still conform to both the ES5 and ES6 spec. ES6 will normatively require block-nested function declarations to be supported, with certain semantics. So I don't agree that a conforming ES6 implementation could reject such functions in blocks. You continued: > The easy fix is to make "use strict"; a triggering condition. I agree that this follows from the state label definitions (whatever their names) and the state machine. Then you wrote: > For non-strict code, by the state machine, the ES6 spec would still delegate > to the ES5 spec. And the ES6 spec would otherwise be the same. But the strict > portion of the ES5 spec would simply be dead code, because all of the > conditions that would trigger it have already triggered the state machine > into using the ES5 spec. Here again I'm confused. the ES6 spec is not going to delegate to a separate and older edition, namely ES5. It will be self-contained. So there must be something in the ES6 spec that defines how to process "use strict"; *or* new ES6 syntax, and how that makes duplicate formals an early error, etc. etc. IOW ECMA-262 Ed. 6 must contain some kind of state machinery for specifying opt-in. > In the ES6 era, I hope to be able to say "ES5-strict is dead. Long live ES6!". Ok, I can adjust labels to agree with this. But it doesn't relieve the ES6 spec from talking about opt-in from ES5-nonstrict, so are we really just arguing about names or labels? If so, great -- those are important to get right. If I seemed to disagree on number of modes, it may be because I don't see how a conforming ES6 implementation could continue to reject extensions that ES5-strict rejects (e.g., functions in blocks). ES6 will require functions-in-blocks to work a certain way. Any implementation that supported an extension under ES5-strict where the semantics for the same syntax differ between the extension and ES6 will have to suffer (SpiderMonkey let and const fall into this category). But that is SpiderMonkey's headache, not ECMA-262's. > However, ES5-non-strict (or "non-strict", or "ES3") will continue to live for > the foreseeable future. It will probably outlive most of us. Yup. /be > > > > > /be > > > > > > ES6-only => (
Re: ES6 doesn't need opt-in
On Jan 7, 2012, at 8:39 PM, Brendan Eich wrote: > Remember, we are not proposing breaking semantic shifts of meaning for > existing syntax. So the realistic worry is that you have code with > arguments[i] aliasing a formal, and this is required for correct operation, > and you then start using ES6 features (which imply ES5-strict), which breaks > arguments aliasing. Hmmm, I was thinking this proposal implied much more of a breaking change (e.g. removing the global object from scope), but if the change in semantics largely comes down to enabling ES5-strict then maybe this isn't so bad. If we are talking about implicitly enabling ES5-strict for the whole program, I would think there may be a quite a few more hazards to consider? (code that implicitly introduces variables onto the global object, assumes this conversion to global object value in function calls, uses callee/caller/arguments, etc). Still, I'm warming up to the idea considerably if the implicit opt-in is triggering no major breaking changes. G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 7, 2012, at 23:22 , Claus Reinke wrote: > But the new plan reminds me strongly of bad experiences in Haskell-land. That sounds interesting. Is this documented somewhere? -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 7, 2012, at 8:00 PM, Gavin Barraclough wrote: > Would the implicit opt-in proposal not mean that any programmer wanting to > pick up JavaScript would need to learn the history of when different > syntactic constructs came into the language specification in order to > understand the semantics that a given script would be evaluated with? If there's new syntax somewhere, the consumer of the code may have to read and understand it. But let's be real: JQuery users *do not* read and understand that library's every line. They use its well-documented APIs. Remember, we are not proposing breaking semantic shifts of meaning for existing syntax. So the realistic worry is that you have code with arguments[i] aliasing a formal, and this is required for correct operation, and you then start using ES6 features (which imply ES5-strict), which breaks arguments aliasing. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 7, 2012, at 2:22 PM, Claus Reinke wrote: > Could you please clarify for me: if I get a single-file codebase, > say jquery's 6k or so lines, will I have to scan the whole file for > ES6-only features before I can even tell whether to apply ES6 > or ES5 semantics? And will this problem increase by one level > with every future version of ES? > > Btw, I'm really uncomfortable with implicit feature tracking - > it works ok for people who follow all the relevant mailinglist > discussions and spec versions, but it leaves in the dark all those > who "just code in JS" and enter a situation where their code base > might have to be interpreted according to any of a number of > specs (most JS coders do not even read one version of the spec, > but rely on blogs and books, which will equally show no explicit > in-source sign of what spec version their examples refer to and > whether they are out of date). I share these concerns. Would the implicit opt-in proposal not mean that any programmer wanting to pick up JavaScript would need to learn the history of when different syntactic constructs came into the language specification in order to understand the semantics that a given script would be evaluated with? G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
if current construct is in ES6-only, abort current compilation and
restart from beginning, starting in State ES6
Basically using any ES6 features makes it an ES6 program. Using any
ES5-only feature makes it an ES5 program.
Combining ES5-only and ES6 features results in an invalid program.
If a Program can not be explicitly identified as either ES5 or ES6, it is
treated as an ES5 program.
Could you please clarify for me: if I get a single-file codebase,
say jquery's 6k or so lines, will I have to scan the whole file for
ES6-only features before I can even tell whether to apply ES6
or ES5 semantics? And will this problem increase by one level
with every future version of ES?
ES5 already has the var-"hoisting" oddity where I might have
to scan the whole file before being able to decide whether a
given variable occurrence is bound to a given variable declaration.
I'm not alone in not wanting to see (another) such hazard (*).
Btw, I'm really uncomfortable with implicit feature tracking -
it works ok for people who follow all the relevant mailinglist
discussions and spec versions, but it leaves in the dark all those
who "just code in JS" and enter a situation where their code base
might have to be interpreted according to any of a number of
specs (most JS coders do not even read one version of the spec,
but rely on blogs and books, which will equally show no explicit
in-source sign of what spec version their examples refer to and
whether they are out of date).
Making feature-based versioning explicit (by pragma opt-in)
doesn't solve all problems, but at least everybody knows what
everyone else is talking about, and help can be offered ("if you
want ES6 semantics for let and yield, write 'use let,yield' or just
'use ES6', if you want JS1.8 semantics for these features, use ..;
if you want to concatenate old and new code, protect the old
code with 'use ES5' and the new code with 'use ES6'").
By making feature-based versioning implicit (by feature use), only
experts will be able to say "wait, I remember that kind of issue -
perhaps your engine has switched to another ES version. could
you check whether your source has any yields in it, or perhaps
destructuring, or perhaps a with, or perhaps a vat? yes, please
check even seemingly unrelated parts of the source.".
Also, what happened to the bold "this version will break a few
things, but we'll end up with a much cleaner language spec"?
I'm not saying you are wrong - if you can pull it off, great! But the
new plan reminds me strongly of bad experiences in Haskell-land.
Claus
(*) At least one popular tool (jslint) has decided not to implement
the resulting 2-pass complexity (find var declarations, then parse
for real) but restricts the input language instead, and makes do
with a single pass over the source and naïve scope-tracking.
If I remember correctly, simply lifting jslint's unpopular vars-first
restriction would lead to incorrect internal scope tracking (I don't
know how jshint handles this, btw?).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
[Standardizing The Magic __proto__ Property] feedback
Hi,
I have some feedback on the strawman in its current form.
First, a cosmetic one, at 4. is written "...(FF already acts this way,
so my previous message was wrong in claiming that Object.create(null)
fails to avoid this platform on all non-IE browsers.)". I think this is
a left-over from a copy/paste of the initial email.
The strawman often refers to "context" or "frame" (item 5,
[[ProtoSetter]] step 2) and I'm not sure this notion is defined in
ECMAScript. Could a definition be added?
"The previous item presents a problem for proxies. With __proto__'s
setter being normative optional, should proxies also have a normative
optional trap for attempts to set their [[Prototype]]? If so, then
presumably there should also be such an operation in that context's
@reflect module. In that case, it no longer clear what to do to lock
down a context so that the [[Prototype]] of its objects can no longer be
mutated."
=> A broader question is whether __proto__ is meant to stay.
__proto__ started as a Mozilla-specific thing, later added by
JavaScriptCore, V8 and Opera engine.
Mozilla had the project to remove it [1]. It generated a long thread
started by John-David Dalton ("Standardizing __proto__"). One notable
answer by Brendan [2] suggested a plan to eventually get rid of __proto__.
Some recent information [3] tells us that the mobile ecosystem is
dominated by __proto__-capable browsers. As a consequence, in mobile,
some authors would take __proto__ for granted. So much that Microsoft
would be considering to implement it, thus re-questionning the intention
to eventually get rid of __proto__.
If __proto__ is meant to stay, considering adding a normative optional
trap and a function in the @reflect module seems necessary. If __proto__
is only codified for the purpose of aligning current implementations for
better security&interoperability with the eventual intention to get rid
of it according to the plan Brendan described, then the trap and
@reflect functions do not seem necessary.
I think that the question is: is __proto__ meant to stay?
An alternative to __proto__ as optional normative could be __proto__ as
optional normative in ES5 and disabled for ES6 (but it would require an
opt-in different from "use strict"; since ES5 strict mode and __proto__
currently coexist in some browsers)
[[ProtoSetter]] algorithm
=> Current implementations prevent prototype chain cycles, the
algorithm, as described doesn't seem to prevent this.
David
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=642500
[2] https://mail.mozilla.org/pipermail/es-discuss/2011-March/013162.html
[3] https://mail.mozilla.org/pipermail/es-discuss/2011-December/019083.html
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Hi, I think Allen had another point. What you are counting, are semantic modes of the code, that is, runtime. What Allen counts, are specification modes of the language, that is, compilation. These are different beans, as he said earlier. Things that Allen defines (afaict) are: - compilation targets ES5 ::= "When run, the program will be interpreted according to ES5 spec. In particular, parts with "use strict"; will be interpreted with ES5 strict mode semantics and parts without it with ES5 non-strict mode semantics. In other words, it will be compiled according to ES5 spec." ES6 ::= "When run, the program will be interpreted according to ES6 spec. In particular, parts with "use strict"; will be interpreted with ES6 (strict) mode semantics and part without it also with ES6 (strict) mode semantics. In other words, it will be compiled according to ES5 spec." - categories of the code elements with respect to compilation targets (they are event in the pre-compilation parsing state machine) Identical-in-both (ES5&ES6), Valid-but-differs (ES5~ES6), Valid-only-in-ES5 (ES5-only), Valid-only-in-ES6 (ES6-only) - states and transitions of the pre-compilation parsing state machine 5&6, ES5, ES6, Compat5 states transitions for all of them with respect to events above (that is, categories) The output of the state machine is the compilation target (inferred directly from the state at which the state machine finishes: ES5, ES5, ES6 and ES5, respectively), eventually an early error that prevents compilation because of conflicting ES5-only and ES6-only code was detected while parsing. "use strict"; and its two modes are only important here, when the program is being compiled (when in state machine, it should imo trigger "Identical-in-both" event). He also recommends opt-ins to be sure to get ES5 target or ES6 target (unless there is conflict in code, of course) as the output of the state machine by citing pieces of code with no functionality but triggering "Valid-only-in-ES5" or "Valid-only-in-ES6" events in the parsing state machine, thereby fixing its state to ES5 or ES6. Herby -Pôvodná správa- From: Mark S. Miller Sent: Saturday, January 07, 2012 4:29 AM To: Axel Rauschmayer Cc: Brendan Eich ; es-discuss Steen Subject: Re: ES6 doesn't need opt-in Axel, thanks. This is the critical point, so no apologies needed for belaboring. Allen, what I mean is exactly what Axel says here. Look at it another way. Right now we have two normative modes: ES5 strict and ES5 non-strict. State machine aside, ES6 introduces a new single mode normative spec. If the state machine may delegate to any of these three normative specs we have three modes. If the state machine may only delegate to ES5-non-strict or ES6, i.e., if the ES5-strict spec becomes dead code as of conformance with state machine + ES6 spec, then we have two modes. To get this effect, we need only classify ES5's "use strict"; directive as ES6-only. If any objection to doing so has been stated, I missed it. Is there a reason not to do so? It's a one line change that leaves the rest of your proposal unperturbed and solves this problem. On Fri, Jan 6, 2012 at 12:09 PM, Axel Rauschmayer wrote: Rather, we should minimize the state machine and how we talk about it. We could generalize it using Curr, Next, Curr&Next, and Curr-Next labels. I’m awfully sorry for belaboring this point. But the labels and the quote below don’t go together. Quoting Brendan: - ES6 is a superset of ES5.strict. That's always been promised. Then I would only expect two labels: ES6 and non-strict ES6-only => (a subset of) ES6 ES5-only => only possible for non-strict constructs => non-strict ES5&ES6 => (a subset of) ES6 ES5~EAS6 => not possible (“The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics.”) -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
