On Nov 29, 2013, at 5:21 PM, Kevin Smith wrote:
x = { use strict; with (x) {} } // Not a strict-mode error
Spec bug if so -- that should make the arrow function so stated have strict
code.
That would probably be the expectation, and I'm possibly just missing
something in the
Jason suggests keeping the token stream and backing up. Another
alternative is remembering the source position of the start of the
parameter list and reparsing when the ambiguity and strictness is resolved.
Whether text, token, or AST based reprocessing is better is an
implementation
Kevin Smith wrote:
x = { use strict; with (x) {} } // Not a strict-mode error
Spec bug if so -- that should make the arrow function so stated
have strict code.
That would probably be the expectation, and I'm possibly just missing
something in the spec. It does add an
This is no different from
function f(x = function(y) { delete y }) { use strict; }
It is in the sense that in the case you present, you already known by
virtue of the function keyword that you are entering a maybe strict
context.
But I was able to program around it - not a huge deal.
Kevin Smith wrote:
sense that in the case you present, you already known by virtue of the
function keyword that you are entering a maybe strict context.
True, with arrows, there's a bit more No one expects the Spanish
Inquisition ;-). But only a bit more.
/be
On Nov 28, 2013, at 1:44 PM, Kevin Smith wrote:
'yield' is already disallowed in generator function default initializer
expressions (although I was reviewing the latest spec. revision yesterday and
there may still be still bugs I have to fix in that regard).
The reason it isn't
OK. One last question: I'm reading that the strictness of arrow functions
is determined only the strictness of their enclosing context, and not by
any prologues inside of them. True?
x = { use strict; with (x) {} } // Not a strict-mode error
___
Kevin Smith wrote:
OK. One last question: I'm reading that the strictness of arrow
functions is determined only the strictness of their enclosing
context, and not by any prologues inside of them. True?
x = { use strict; with (x) {} } // Not a strict-mode error
Spec bug if so -- that
x = { use strict; with (x) {} } // Not a strict-mode error
Spec bug if so -- that should make the arrow function so stated have
strict code.
That would probably be the expectation, and I'm possibly just missing
something in the spec. It does add an extra degree of complexity, though.
function*(a = yield/b/g) {
a = yield/b/g;
}
Why allow yield as an identifier in parameter defaults of generators?
Wouldn't it be simpler just to disallow there as well?
___
es-discuss mailing list
es-discuss@mozilla.org
Kevin Smith wrote:
function*(a = yield/b/g) {
a = yield/b/g;
}
Why allow yield as an identifier in parameter defaults of generators?
Wouldn't it be simpler just to disallow there as well?
When proposing an irregularity, you need a better reason than why allow?
Parameter
On Nov 28, 2013, at 10:40 AM, Brendan Eich wrote:
Kevin Smith wrote:
function*(a = yield/b/g) {
a = yield/b/g;
}
Why allow yield as an identifier in parameter defaults of generators?
Wouldn't it be simpler just to disallow there as well?
When proposing an
On Nov 28, 2013, at 11:24 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
The reason it isn't allowed is that the generator object is not yet
instantiated and active at the point where a default value initializer would
be evaluated.
But just to be clear, defaults are evaluated per
On Nov 28, 2013, at 11:47 AM, Brendan Eich wrote:
On Nov 28, 2013, at 11:24 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
The reason it isn't allowed is that the generator object is not yet
instantiated and active at the point where a default value initializer would
be evaluated.
'yield' is already disallowed in generator function default initializer
expressions (although I was reviewing the latest spec. revision yesterday
and there may still be still bugs I have to fix in that regard).
The reason it isn't allowed is that the generator object is not yet
instantiated
But IIRC (and from reading http://people.mozilla.org/~
jorendorff/es6-draft.html, looking for LetOrConst uses), ES6 supports let
in all contexts, reserved word or not.
Yes, I see that now. Has anyone done compatibility-hazard analysis for
this breaking change?
;
let[a].foo() //
On Mon, Nov 25, 2013 at 7:00 PM, Kevin Smith zenpars...@gmail.com wrote:
To use Waldemar's word, I wonder if that might get obnoxious:
function(a = function(yield = function(arguments = function(eval) {})
{}) {}) {
use strict; /* Doh! */
}
Implementation note: It is super
Implementation note: It is super obnoxious.
+1 for adding that note to the spec : ) j/k
It all just makes me wonder if we're better off saying: Forget the 'use
strict' prologue, it's foobar. For strictness, use classes and modules
instead.
In no way am I trying to recall a sailed ship
Jason Orendorff wrote:
On Mon, Nov 25, 2013 at 7:00 PM, Kevin Smithzenpars...@gmail.com wrote:
To use Waldemar's word, I wonder if that might get obnoxious:
function(a = function(yield = function(arguments = function(eval) {})
{}) {}) {
use strict; /* Doh! */
}
On Nov 26, 2013, at 11:36 AM, Brendan Eich wrote:
Kevin Smith wrote:
Yes, I see that now. Has anyone done compatibility-hazard analysis for this
breaking change?
;
let[a].foo() // Fine in ES5 non-strict, fails in ES6?
That old chestnut! (Unquote a for better ambiguity.)
Allen Wirfs-Brock wrote:
I honestly forget how we decided to go for let at start of statement
followed by [ -- but I do recall we agreed not to have
name-binding-sensitive parsing(!). I.e., we would not look for 'var
let = ...' and treat 'let' in that (hoisted) scope as a non-keyword.
Thanks. I should have looked -- at this point es6-draft seems to have
almost all of the wanted answers. Great work, keep going!
Agreed, thank you Allen for bearing with me!
___
es-discuss mailing list
es-discuss@mozilla.org
On 11/25/2013 04:48 PM, Brendan Eich wrote:
Brendan Eich wrote:
Kevin Smith wrote:
This makes for wtfjs additions, but they all seem non-wtf on
reflection (or did to us when Waldemar threw them up on a
whiteboard last week). By non-wtf, I mean anyone who groks that
yield is
Jason Orendorff wrote:
As long as
it's impossible to have code that parses in both modes, with different
meanings, it's not so bad.
Then we could have trouble, but perhaps do not:
function f(a = arguments[0] = 42) {
use strict;
...
}
The use strict defeats arguments aliasing at runtime.
Jason Orendorff wrote:
SpiderMonkey rewinds the token stream and re-parses.
I'm past the point of feeling sheepish about it, honestly. The code
would have to be super strange for us to rewind much (but yes, in the
worst case we can be O(n^2)). The rewinding code is fairly clean and
localized.
Brendan Eich wrote:
function f(a = arguments[1] = 42, b) {
use strict;
...
}
Fixed as cited above -- what I'd written had no observably different
outcome in sloppy vs. strict mode.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
Mark S. Miller wrote:
Hi Brendan, I'm not sure I understand the question. Statically, strict
= sloppy. Dynamically, these are strict arguments, so there's no
aliasing. The code parses one way independent of strictness.
Strictness determines in retrospect what it means, but does not need
to
Allen Wirfs-Brock wrote:
In this case there are no static semantic differences between strict and sloppy
mode. The difference is in the runtime semantics associated with s [[Set]] on
the arguments object.
In spec-land, this distinction is made during the
FunctionDeclarationInstantiation
Apologies for this remedial question, but I find the new grammar
parameterized around [Yield] to be confusing. If I understand correctly,
this is to allow yield within non-strict generators. If that's correct,
then why are non-strict generators a good idea?
Thanks!
Where can I see this new grammar? Is this up somewhere?
On Mon, Nov 25, 2013 at 2:03 PM, Kevin Smith zenpars...@gmail.com wrote:
Apologies for this remedial question, but I find the new grammar
parameterized around [Yield] to be confusing. If I understand correctly,
this is to allow yield
It is in the latest spec draft at
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
On Mon, Nov 25, 2013 at 5:38 PM, Matthew Robb matthewwr...@gmail.comwrote:
Where can I see this new grammar? Is this up somewhere?
On Mon, Nov 25, 2013 at 2:03 PM, Kevin Smith
On 11/25/2013 02:03 PM, Kevin Smith wrote:
Apologies for this remedial question, but I find the new grammar parameterized
around [Yield] to be confusing. If I understand correctly, this is to allow
yield within non-strict generators. If that's correct, then why are non-strict
generators a
function(a = yield+b) {
use strict;
}
Ah, thanks for pointing out the function-head issue. So for non-strict
regular functions, is yield allowed in parameter initializers or not?
___
es-discuss mailing list
es-discuss@mozilla.org
Kevin Smith wrote:
function(a = yield+b) {
use strict;
}
Ah, thanks for pointing out the function-head issue. So for
non-strict regular functions, is yield allowed in parameter
initializers or not?
Sure -- yield is just an identifier there.
This makes for wtfjs additions,
This makes for wtfjs additions, but they all seem non-wtf on reflection
(or did to us when Waldemar threw them up on a whiteboard last week). By
non-wtf, I mean anyone who groks that yield is reserved only in function*
can work them out.
The star after function really helps. ES5's use
Kevin Smith wrote:
This makes for wtfjs additions, but they all seem non-wtf on
reflection (or did to us when Waldemar threw them up on a
whiteboard last week). By non-wtf, I mean anyone who groks that
yield is reserved only in function* can work them out.
The star after
Brendan Eich wrote:
Kevin Smith wrote:
This makes for wtfjs additions, but they all seem non-wtf on
reflection (or did to us when Waldemar threw them up on a
whiteboard last week). By non-wtf, I mean anyone who groks that
yield is reserved only in function* can work them out.
So we parse it as an identifier, just as we parse duplicate formal
parameters. Then if we see use strict, we must post-process the parse
tree and throw an error. Kind of a shame, but there it is.
To use Waldemar's word, I wonder if that might get obnoxious:
function(a = function(yield
On Nov 25, 2013, at 4:21 PM, Kevin Smith wrote:
This makes for wtfjs additions, but they all seem non-wtf on reflection (or
did to us when Waldemar threw them up on a whiteboard last week). By non-wtf,
I mean anyone who groks that yield is reserved only in function* can work
them out.
Kevin Smith wrote:
To use Waldemar's word, I wonder if that might get obnoxious:
function(a = function(yield = function(arguments = function(eval)
{}) {}) {}) {
use strict; /* Doh! */
}
That's no different in kind from the ES5 + default parameters combo:
function f(a =
On Nov 25, 2013, at 5:00 PM, Kevin Smith wrote:
So we parse it as an identifier, just as we parse duplicate formal
parameters. Then if we see use strict, we must post-process the parse tree
and throw an error. Kind of a shame, but there it is.
To use Waldemar's word, I wonder if that
The handling of 'yield' in this case is no more obnoxious than any of the
other strict mode restriction that apply to those functions that are
defined in the parameter list.
Agreed. My Homer Simpson joke was just trying to point out that
(irrespective of `yield`, per se), post-validating
Thanks Allen, this clears up the yield situation for me.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Kevin Smith wrote:
Agreed. My Homer Simpson joke was just trying to point out that
(irrespective of `yield`, per se), post-validating default arguments
in light of a later-seen use strict directive could require
re-validation of the entire parse tree for function expressions
included in
The other option (I say this bracing for pain), is to avoid potential
full-tree re-validation by applying strictness to parameter bindings only,
and not to default expressions.
This option might not be so bad if you consider that (a) code will
gradually be moving into implicitly strict contexts
Allen,
What's the rationale for not making generator functions implicitly strict?
Implicit strictness seems natural for new function forms, minus arrows.
Looking forward, I have a hard time imagining that we'll want, say, async
functions to be non-strict.
I probably just missed some discussion
The idea was to treat them as similarly to 'function' as possible, because * is
such a small syntactic difference
Kevin Smith zenpars...@gmail.com wrote:
Allen,
What's the rationale for not making generator functions implicitly strict?
Implicit strictness seems natural for new function
The idea was to treat them as similarly to 'function' as possible, because
* is such a small syntactic difference
Makes sense, although on the other side you have a huge semantic
difference, little refactoring hazard, and `yield` already reserved.
Thanks again!
-
Kevin Smith wrote:
The idea was to treat them as similarly to 'function' as possible,
because * is such a small syntactic difference
Makes sense, although on the other side you have a huge semantic
difference, little refactoring hazard, and `yield` already reserved.
Yes, it's
Validating default parameters against strict mode seems no worse in kind
(if not degree) than validating parameter lists against duplicates was in
ES5 days. Gross, but doable and I think better than leaving default
expressions non-strict.
Perhaps you're right. In addition to what we're
Perhaps you're right. In addition to what we're doing already in ES5 and
now ES6 destructuring patterns, I suppose you'd need to recurse into
default expressions and look for any bad `delete` expressions, any
WithStatements, and any bad BindingIdentifiers. And rinse and repeat with
any
Kevin Smith wrote:
I wonder if you'd need to go back to the lexer in some cases:
function(a = let) {
use strict;
}
After seeing the use strict, I'd have to go back and re-scan the
let to find out that it was actually a keyword in this context (and
hence a syntax error).
The
Brendan Eich wrote:
Kevin Smith wrote:
I wonder if you'd need to go back to the lexer in some cases:
function(a = let) {
use strict;
}
After seeing the use strict, I'd have to go back and re-scan the
let to find out that it was actually a keyword in this context (and
hence a
53 matches
Mail list logo
