Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
Allen mentioned that `String#at` might not make it to ES6 because nobody in TC39 is championing it. I’ve now asked Rick if he would be the champion for this, and he agreed. (Thanks again!) Looking over the ‘TC39 progress’ document at https://docs.google.com/a/chromium.org/document/d/1QbEE0BsO4lvl7NFTn5WXWeiEIBfaVUF7Dk0hpPpPDzU, it seems most of the work is already taken care of: the use case was discussed in this thread, the proposal has a complete spec text, and there’s an example implementation/polyfill with unit tests. See http://mths.be/at. Is there anything else I can do to help get this included as a non-TC39-member? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
This was the method that was only useful if you pass `0` to it? -Original Message- From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Mathias Bynens Sent: Friday, February 14, 2014 10:34 To: Rick Waldron; Allen Wirfs-Brock Cc: es-discuss@mozilla.org list Subject: Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`) Allen mentioned that `String#at` might not make it to ES6 because nobody in TC39 is championing it. I've now asked Rick if he would be the champion for this, and he agreed. (Thanks again!) Looking over the 'TC39 progress' document at https://docs.google.com/a/chromium.org/document/d/1QbEE0BsO4lvl7NFTn5WXWeiEIBfaVUF7Dk0hpPpPDzU, it seems most of the work is already taken care of: the use case was discussed in this thread, the proposal has a complete spec text, and there's an example implementation/polyfill with unit tests. See http://mths.be/at. Is there anything else I can do to help get this included as a non-TC39-member? ___ 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
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
Note that `Array.from(str)` and `str[Symbol.iterator]` overlap significantly. In particular, it's somewhat awkward to iterate over code points using `String#symbolAt`; it's much easier to use `substr()` and then use the StringIterator. --scott ps. I see that Domenic has said something similar. On Thu, Feb 13, 2014 at 11:34 PM, Mathias Bynens math...@qiwi.be wrote: Allen mentioned that `String#at` might not make it to ES6 because nobody in TC39 is championing it. I’ve now asked Rick if he would be the champion for this, and he agreed. (Thanks again!) Looking over the ‘TC39 progress’ document at https://docs.google.com/a/chromium.org/document/d/1QbEE0BsO4lvl7NFTn5WXWeiEIBfaVUF7Dk0hpPpPDzU, it seems most of the work is already taken care of: the use case was discussed in this thread, the proposal has a complete spec text, and there’s an example implementation/polyfill with unit tests. See http://mths.be/at. Is there anything else I can do to help get this included as a non-TC39-member? ___ 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
Re: MonadicPromises, revisited
On 14 February 2014 00:32, C. Scott Ananian ecmascr...@cscott.net wrote:
For your consideration, here is an implementation of Monadic Promises,
as a Promise subclass:
Since promises are expressible in JS you can always create a new class
that does what you want. It's also well-understood that you can do
that using the existing class by wrapping all resolution values.
The fundamental problem, however, is that existing producers will not
give you instances of the new class, which makes it rather useless in
most cases.
Whether the new class is a subclass or not is mostly immaterial
regarding that problem. In fact, I would argue that it is incorrect to
implement it via subclassing, since you are effectively using a
different internal representation (a wrapped value) that the base
class methods do not recognize. If, for example, somebody was to add a
method like
value() {
if (this.status != resolved) throw TypeError;
return this.value;
}
to the base class then it would not work properly with subclass
instances. In other words, this form of subclassing violates
substitutability.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On 14 Feb 2014, at 11:11, Domenic Denicola dome...@domenicdenicola.com wrote: This was the method that was only useful if you pass `0` to it? I’ll just avoid the infinite loop here by pointing to earlier posts in this thread where this was discussed before: http://esdiscuss.org/topic/string-prototype-symbolat-improved-string-prototype-charat#content-34 and http://esdiscuss.org/topic/string-prototype-symbolat-improved-string-prototype-charat#content-40. This method is just as useful as `String.prototype.codePointAt`. If that method is included, so should `String.prototype.at`. If `String.prototype.at` is found not to be useful, `String.prototype.codePointAt` should be removed too. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On 14 Feb 2014, at 11:14, C. Scott Ananian ecmascr...@cscott.net wrote: Note that `Array.from(str)` and `str[Symbol.iterator]` overlap significantly. In particular, it's somewhat awkward to iterate over code points using `String#symbolAt`; it's much easier to use `substr()` and then use the StringIterator. `String#at` is not meant for iterating over code points – that’s what the `StringIterator` is for. `String#at` is exactly like `String#codePointAt` except it returns strings (containing the symbol) instead of numbers (representing the code point value). It can be used to get the symbol at a given code unit position in a string (similar to how `String#codePointAt` can be used to get the code point at a given code unit position in a string). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
Yes, I know what `String#at` is supposed to do. I was pointing out that `String#at` makes it easy to do the wrong thing. If you do `Array.from(str)` then you suddenly have a complete random-access data structure where you can find out the number of code points in the String, iterate it in reverse from the end to the start, slice it, find the midpoint, etc. `Array.from` looks like an O(n) operation, and it is -- so it encourages developers to cache the value and reuse it. That said, I can see where a lexer might want to use `String#at`, being careful to do the correct index bump based on `result.length`. However, the fastest JS lexers don't create String objects, they operate directly on the code point (see http://marijnhaverbeke.nl/acorn/#section-58). So I'm -0, mostly because the name isn't great. But I have exactly zero say in the matter anyway. So I'll shut up now. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
I think Mathias's point, that it is exactly as useful or useless as `codePointAt`, is a reasonable one. However, This method is just as useful as `String.prototype.codePointAt`. If that method is included, so should `String.prototype.at`. If `String.prototype.at` is found not to be useful, `String.prototype.codePointAt` should be removed too. This does not follow. The choice is not between adding two useless methods and adding zero. There is no reason to exclude the possibility of adding only one useless method. But anyway, as some people seem to think that both methods are in fact useful---including Rick, who has agreed to champion---I agree with Scott that after having said our piece it's time to exit the thread. -Original Message- From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of C. Scott Ananian Sent: Friday, February 14, 2014 12:12 To: Mathias Bynens Cc: es-discuss@mozilla.org list Subject: Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`) Yes, I know what `String#at` is supposed to do. I was pointing out that `String#at` makes it easy to do the wrong thing. If you do `Array.from(str)` then you suddenly have a complete random-access data structure where you can find out the number of code points in the String, iterate it in reverse from the end to the start, slice it, find the midpoint, etc. `Array.from` looks like an O(n) operation, and it is -- so it encourages developers to cache the value and reuse it. That said, I can see where a lexer might want to use `String#at`, being careful to do the correct index bump based on `result.length`. However, the fastest JS lexers don't create String objects, they operate directly on the code point (see http://marijnhaverbeke.nl/acorn/#section-58). So I'm -0, mostly because the name isn't great. But I have exactly zero say in the matter anyway. So I'll shut up now. --scott ___ 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
System.import FTW
Can someone point me to the spec for `System.import`?
https://github.com/jorendorff/js-loaders/blob/master/browser-loader.js
doesn't seem to include it.
It seems to me that it would be worthwhile to ensure that
`System.import` had good semantics. It would allow a nice migration
path for existing AMD and node-style modules. For example:
```js
// AMD-style define!
// (Promise.map and Promise.spread would be nice here; see
// https://github.com/cscott/prfun)
function define(deps, f) {
return Promise.all(deps.map(d = System.import(d)))
.then( (...args) = f(...args) )
.then( registerModule )
}
```
and
```js
// Node-style require needs more magic.
Promise.async(function*() {
/* start module text */
var fs = yield System.import('fs');
// etc.
/* end module text */
return module.exports;
}).then( registerModule );
```
But that implies that `System.import` has well defined cycle-breaking,
extensibility, etc. Could it?
--scott
ps. https://gist.github.com/wycats/51c96e3adcdb3a68cbc3/#comment-1006744
--
( http://cscott.net/ )
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: System.import FTW
On 14 February 2014 14:13, C. Scott Ananian ecmascr...@cscott.net wrote:
Can someone point me to the spec for `System.import`?
It's in the ES6 specification draft under Loader.prototype.import -
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-loader.prototype.import
.
https://github.com/jorendorff/js-loaders/blob/master/browser-loader.js
doesn't seem to include it.
It seems to me that it would be worthwhile to ensure that
`System.import` had good semantics. It would allow a nice migration
path for existing AMD and node-style modules. For example:
```js
// AMD-style define!
// (Promise.map and Promise.spread would be nice here; see
// https://github.com/cscott/prfun)
function define(deps, f) {
return Promise.all(deps.map(d = System.import(d)))
.then( (...args) = f(...args) )
.then( registerModule )
}
```
This is not the recommended way to register a module - rather this is what
Dynamic Instantiation is designed to handle for you, so there is no need to
work out how to link the dependencies manually. See
https://gist.github.com/dherman/7568080 or the outdated (using old syntax,
but the principles remain) essay
https://gist.github.com/wycats/51c96e3adcdb3a68cbc3 for more info.
and
```js
// Node-style require needs more magic.
Promise.async(function*() {
/* start module text */
var fs = yield System.import('fs');
// etc.
/* end module text */
return module.exports;
}).then( registerModule );
```
Again, this is solved by dynamic instantiation.
But that implies that `System.import` has well defined cycle-breaking,
extensibility, etc. Could it?
--scott
ps. https://gist.github.com/wycats/51c96e3adcdb3a68cbc3/#comment-1006744
--
( http://cscott.net/ )
___
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
Re: restrictions on let declarations
On 30/01/2014, at 17:13, Brendan Eich wrote:
John Barton wrote:
On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
John Lenz wrote:
Generally, I've always thought of:
if (x) ... as equivalent to if (x) { ... }
let and const (and class) are block-scoped. {...} in your if (x)
{...} is a block. An unbraced consequent is not a block, and you
can't have a conditional let binding.
The restriction avoids nonsense such as
let x = 0; { if (y) let x = 42; alert(x); }
What pray tell is going on here, in your model?
I'm with John: the alert should say 0 and I can't see why that is not
obvious.
Interesting!
You don't want the alert to show undefined, so the extent of the inner
binding in your model is the unbraced consequent of the if.
That is not block scope in any plain sense.
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
On 31/01/2014, at 03:11, Brendan Eich wrote:
OMG LETS MAKE USELESS LETS EVERYWHERE LOLJSSUXZ0RZ! Um, no.
:-)
--
( Jorge )();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
On 30/01/2014, at 17:13, Brendan Eich wrote: / // // Interesting! // // You don't want the alert to show undefined, so the extent of the inner binding in your model is the unbraced consequent of the if. // // That is not block scope in any plain sense. / How about this? let x= 0; if (1) eval(let x= 42; alert(x);); //Is this in its own block? alert(x); `eval()` hasn't yet been updated to work with the new lexical declaration forms, but I hope the example from above will be evaluated in a new block. See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug report. - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
eval of let, etc. Was: Re: restrictions on let declarations
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical declaration
forms, but I hope the example from above will be evaluated in a new block.
See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug report.
Goood point and this is something I need to specify in the next couple weeks so
let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new environment
that is immediately nested within the current LexicalEnvironment. The scoping
behavior is essentially the same as if the eval code was the body of an iife
that occurred at the same place as the eval call. Bindings introduced by the
eval code disappear after completion of the eval.
In non-strict mode, each eval instantiates all declarations in the current
VariableEnvironment; that is the most immediately enclosing function or global
environment. Bindings introduced by the eval code remain accessible from that
VariableEnvironment after completion of the eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact same way.
Each eval takes place in its own environment and no bindings survive the
completion of the eval.
For ES6, non-strict evals of code containing only var or function declarations
must have exactly the ES5 behavior in order to maintain compatibility. But
what about eval code that contains new declaration forms (let/const/class)
exclusively or in combination with var/function declarations? Three
possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics if the eval code directly contains
any of the new declaration forms:
(function() {
eval(
var answer=42;
let forceSeprateEnvironment = true;
);
console.log(answer); // ReferenceError: answer is not defined
})();
3) Combination. use ES5 non-strict binding semantics for var/function
declarations but place let/const/class bindings into a per eval environment:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // ReferenceError: localToEval is not defined
)();
It would certainly be possible to specify #1, but I don't like it. Other than
for the global environment it would be cleaner if the new block scope-able
declarations were never dynamically added to the environment.
I think either #2 or #3 is plausible. #2 is a simpler story but introduces a
refactoring hazard. If you have some existing eval code that defines some
global functions or variables, then simply adding a let/const/class
declaration to the eval code ruins those global declarations.
I prefer the simplicity of #2, but I also worry about the WTF impact it might
have on evolving existing code.
Can we get away with #2, or are we going to have to go with #3? Are there
other alternatives?
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically
considered a block, the let binding would survive past the completion of
the eval in non-strict mode:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // true
)();
(function() {
use strict;
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // ReferenceError: answer is not defined
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
I'm not necessarily arguing for that behavior, but weighing in since that's
the behavior I would have expected based on existing ES5
strict/non-strict/eval and ES6 let semantics...
On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical declaration
forms, but I hope the example from above will be evaluated in a new block.
See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug
report.
Goood point and this is something I need to specify in the next couple
weeks so let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new
environment that is immediately nested within the current
LexicalEnvironment. The scoping behavior is essentially the same as if the
eval code was the body of an iife that occurred at the same place as the
eval call. Bindings introduced by the eval code disappear after completion
of the eval.
In non-strict mode, each eval instantiates all declarations in the current
VariableEnvironment; that is the most immediately enclosing function or
global environment. Bindings introduced by the eval code remain accessible
from that VariableEnvironment after completion of the eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact same
way. Each eval takes place in its own environment and no bindings survive
the completion of the eval.
For ES6, non-strict evals of code containing only var or function
declarations must have exactly the ES5 behavior in order to maintain
compatibility. But what about eval code that contains new declaration
forms (let/const/class) exclusively or in combination with var/function
declarations? Three possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics if the eval code directly
contains any of the new declaration forms:
(function() {
eval(
var answer=42;
let forceSeprateEnvironment = true;
);
console.log(answer); // ReferenceError: answer is not defined
})();
3) Combination. use ES5 non-strict binding semantics for var/function
declarations but place let/const/class bindings into a per eval environment:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
It would certainly be possible to specify #1, but I don't like it. Other
than for the global environment it would be cleaner if the new block
scope-able declarations were never dynamically added to the environment.
I think either #2 or #3 is plausible. #2 is a simpler story but
introduces a refactoring hazard. If you have some existing eval code that
defines some global functions or variables, then simply adding a
let/const/class declaration to the eval code ruins those global
declarations.
I prefer the simplicity of #2, but I also worry about the WTF impact it
might have on evolving existing code.
Can we get away with #2, or are we going to have to go with #3? Are there
other alternatives?
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
On Fri, Feb 14, 2014 at 7:40 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
[...]
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics if the eval code directly
contains any of the new declaration forms:
(function() {
eval(
var answer=42;
let forceSeprateEnvironment = true;
);
console.log(answer); // ReferenceError: answer is not defined
})();
3) Combination. use ES5 non-strict binding semantics for var/function
declarations but place let/const/class bindings into a per eval environment:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
It would certainly be possible to specify #1, but I don't like it. Other
than for the global environment it would be cleaner if the new block
scope-able declarations were never dynamically added to the environment.
I think either #2 or #3 is plausible. #2 is a simpler story but
introduces a refactoring hazard. If you have some existing eval code that
defines some global functions or variables, then simply adding a
let/const/class declaration to the eval code ruins those global
declarations.
I prefer the simplicity of #2, but I also worry about the WTF impact it
might have on evolving existing code.
Can we get away with #2, or are we going to have to go with #3? Are there
other alternatives?
I actually prefer #3. Given only knowledge of ES5 and of the rest of ES6, I
find it least surprising. vars hoist out of blocks. In non-strict code,
functions leak out of blocks in ways that are hard to explain. I can
understand non-strict direct eval as being block-like, in that var and
function leak out of them, but all the reliably block-local declarations
stay within the direct eval.
Also, I buy the refactoring issue. It's like the problem with micro-modes:
bizarre and unexpected non-local influences.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
I agree that this is in some sense the least surprising. But it is so
unpleasant that I think we should instead opt for the additional surprise
of #3 -- that a direct sloppy eval is block-like, even though there aren't
any curlies.
On Fri, Feb 14, 2014 at 8:03 AM, Jeremy Martin jmar...@gmail.com wrote:
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically
considered a block, the let binding would survive past the completion of
the eval in non-strict mode:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // true
)();
(function() {
use strict;
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // ReferenceError: answer is not defined
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
I'm not necessarily arguing for that behavior, but weighing in since
that's the behavior I would have expected based on existing ES5
strict/non-strict/eval and ES6 let semantics...
On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical declaration
forms, but I hope the example from above will be evaluated in a new block.
See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug
report.
Goood point and this is something I need to specify in the next couple
weeks so let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new
environment that is immediately nested within the current
LexicalEnvironment. The scoping behavior is essentially the same as if the
eval code was the body of an iife that occurred at the same place as the
eval call. Bindings introduced by the eval code disappear after completion
of the eval.
In non-strict mode, each eval instantiates all declarations in the
current VariableEnvironment; that is the most immediately enclosing
function or global environment. Bindings introduced by the eval code
remain accessible from that VariableEnvironment after completion of the
eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact
same way. Each eval takes place in its own environment and no bindings
survive the completion of the eval.
For ES6, non-strict evals of code containing only var or function
declarations must have exactly the ES5 behavior in order to maintain
compatibility. But what about eval code that contains new declaration
forms (let/const/class) exclusively or in combination with var/function
declarations? Three possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics if the eval code directly
contains any of the new declaration forms:
(function() {
eval(
var answer=42;
let forceSeprateEnvironment = true;
);
console.log(answer); // ReferenceError: answer is not defined
})();
3) Combination. use ES5 non-strict binding semantics for var/function
declarations but place let/const/class bindings into a per eval environment:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
It would certainly be possible to specify #1, but I don't like it. Other
than for the global environment it would be cleaner if the new block
scope-able declarations were never dynamically added to the environment.
I think either #2 or #3 is plausible. #2 is a simpler story but
introduces a refactoring hazard. If you have some existing eval code that
defines some global functions or variables, then simply adding a
let/const/class declaration to the eval code ruins those global
declarations.
I prefer the simplicity of #2, but I also worry about the WTF impact it
might have on evolving existing code.
Can we get away with #2, or are we going to have to go with #3? Are
there other alternatives?
Allen
Re: Promise.cast and Promise.resolve
On Fri, Feb 7, 2014 at 11:50 AM, Anne van Kesteren ann...@annevk.nl wrote: I filed https://bugzilla.mozilla.org/show_bug.cgi?id=966348 on Gecko when the news broke. Mozilla can probably still make things in order before promises hit stable. To be clear, we fixed this. And we will be going ahead and shipping promises in Firefox 29. Too many dependencies at this point to hold of longer. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
How about Keyword 'let' not allowed without 'use strict' or in a module. ?
On Fri, Feb 14, 2014 at 8:18 AM, Mark S. Miller erig...@google.com wrote:
I agree that this is in some sense the least surprising. But it is so
unpleasant that I think we should instead opt for the additional surprise
of #3 -- that a direct sloppy eval is block-like, even though there aren't
any curlies.
On Fri, Feb 14, 2014 at 8:03 AM, Jeremy Martin jmar...@gmail.com wrote:
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically
considered a block, the let binding would survive past the completion of
the eval in non-strict mode:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // true
)();
(function() {
use strict;
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // ReferenceError: answer is not defined
console.log(localToEval); // ReferenceError: localToEval is
not defined
)();
I'm not necessarily arguing for that behavior, but weighing in since
that's the behavior I would have expected based on existing ES5
strict/non-strict/eval and ES6 let semantics...
On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical
declaration forms, but I hope the example from above will be evaluated in a
new block. See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a
related bug report.
Goood point and this is something I need to specify in the next couple
weeks so let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new
environment that is immediately nested within the current
LexicalEnvironment. The scoping behavior is essentially the same as if the
eval code was the body of an iife that occurred at the same place as the
eval call. Bindings introduced by the eval code disappear after completion
of the eval.
In non-strict mode, each eval instantiates all declarations in the
current VariableEnvironment; that is the most immediately enclosing
function or global environment. Bindings introduced by the eval code
remain accessible from that VariableEnvironment after completion of the
eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact
same way. Each eval takes place in its own environment and no bindings
survive the completion of the eval.
For ES6, non-strict evals of code containing only var or function
declarations must have exactly the ES5 behavior in order to maintain
compatibility. But what about eval code that contains new declaration
forms (let/const/class) exclusively or in combination with var/function
declarations? Three possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics if the eval code directly
contains any of the new declaration forms:
(function() {
eval(
var answer=42;
let forceSeprateEnvironment = true;
);
console.log(answer); // ReferenceError: answer is not defined
})();
3) Combination. use ES5 non-strict binding semantics for var/function
declarations but place let/const/class bindings into a per eval environment:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
It would certainly be possible to specify #1, but I don't like it. Other
than for the global environment it would be cleaner if the new block
scope-able declarations were never dynamically added to the environment.
I think either #2 or #3 is plausible. #2 is a simpler story but
introduces a refactoring hazard. If you have some existing eval code that
defines some global functions or variables, then simply adding a
let/const/class declaration to the eval code ruins those global
declarations.
I prefer the simplicity of #2, but I also worry about the WTF impact it
might have on
Re: eval of let, etc. Was: Re: restrictions on let declarations
Mark S. Miller wrote: I actually prefer #3. Given only knowledge of ES5 and of the rest of ES6, I find it least surprising. vars hoist out of blocks. In non-strict code, functions leak out of blocks in ways that are hard to explain. I can understand non-strict direct eval as being block-like, in that var and function leak out of them, but all the reliably block-local declarations stay within the direct eval. Also, I buy the refactoring issue. It's like the problem with micro-modes: bizarre and unexpected non-local influences. Yes, agree on #3 being best. My recollection from past TC39 meetings and discussion here is that #2 will not fly. We do not want some let buried in a large string to eval to contaminate the whole eval'ed program such that vars in it are confined, where they weren't before. Just amplifying your refactoring point, but also noting your micro-mode/non-local comment. This is not going to win consensus. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
On Fri, Feb 14, 2014 at 8:26 AM, John Barton johnjbar...@google.com wrote:
How about Keyword 'let' not allowed without 'use strict' or in a module.
?
I wish. I argued strongly that sloppy mode be maintained only to continue
to serve the purpose of being an ES3 compatibility mode, and that we stop
adding new ES6 language features to it. In particular, that we not add
let since we could not even specify that let be *simply* a declaration
keyword in sloppy mode. Instead, TC39 decided that let in sloppy mode is
sometimes a variable, and sometimes indicates a let declaration. This is
long decided and TC39 is not going to revisit the admission of let into
sloppy mode.
For this and many other reasons, new code should consider sloppy mode to be
WTF toxic waste, to be avoided under all normal circumstances.
Nevertheless, we still need to settle outstanding questions as
non-toxically as possible, given the toxic waste we've already dumped into
sloppy mode. Hence this thread.
On Fri, Feb 14, 2014 at 8:18 AM, Mark S. Miller erig...@google.comwrote:
I agree that this is in some sense the least surprising. But it is so
unpleasant that I think we should instead opt for the additional surprise
of #3 -- that a direct sloppy eval is block-like, even though there aren't
any curlies.
On Fri, Feb 14, 2014 at 8:03 AM, Jeremy Martin jmar...@gmail.com wrote:
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically
considered a block, the let binding would survive past the completion of
the eval in non-strict mode:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // true
)();
(function() {
use strict;
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // ReferenceError: answer is not defined
console.log(localToEval); // ReferenceError: localToEval is
not defined
)();
I'm not necessarily arguing for that behavior, but weighing in since
that's the behavior I would have expected based on existing ES5
strict/non-strict/eval and ES6 let semantics...
On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical
declaration forms, but I hope the example from above will be evaluated in a
new block. See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a
related bug report.
Goood point and this is something I need to specify in the next couple
weeks so let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new
environment that is immediately nested within the current
LexicalEnvironment. The scoping behavior is essentially the same as if the
eval code was the body of an iife that occurred at the same place as the
eval call. Bindings introduced by the eval code disappear after completion
of the eval.
In non-strict mode, each eval instantiates all declarations in the
current VariableEnvironment; that is the most immediately enclosing
function or global environment. Bindings introduced by the eval code
remain accessible from that VariableEnvironment after completion of the
eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact
same way. Each eval takes place in its own environment and no bindings
survive the completion of the eval.
For ES6, non-strict evals of code containing only var or function
declarations must have exactly the ES5 behavior in order to maintain
compatibility. But what about eval code that contains new declaration
forms (let/const/class) exclusively or in combination with var/function
declarations? Three possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics if the eval code directly
contains any of the new declaration forms:
(function() {
eval(
var answer=42;
let forceSeprateEnvironment = true;
);
console.log(answer); // ReferenceError: answer is not defined
})();
3) Combination. use ES5 non-strict binding semantics
Re: eval of let, etc. Was: Re: restrictions on let declarations
As far as I can see, your #4 and my #1 are exactly the same. How do you think
they differ?
Allen
On Feb 14, 2014, at 8:03 AM, Jeremy Martin wrote:
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically considered
a block, the let binding would survive past the completion of the eval in
non-strict mode:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // true
)();
(function() {
use strict;
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // ReferenceError: answer is not defined
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
I'm not necessarily arguing for that behavior, but weighing in since that's
the behavior I would have expected based on existing ES5
strict/non-strict/eval and ES6 let semantics...
On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical declaration
forms, but I hope the example from above will be evaluated in a new block.
See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug
report.
Goood point and this is something I need to specify in the next couple weeks
so let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new environment
that is immediately nested within the current LexicalEnvironment. The scoping
behavior is essentially the same as if the eval code was the body of an iife
that occurred at the same place as the eval call. Bindings introduced by the
eval code disappear after completion of the eval.
In non-strict mode, each eval instantiates all declarations in the current
VariableEnvironment; that is the most immediately enclosing function or
global environment. Bindings introduced by the eval code remain accessible
from that VariableEnvironment after completion of the eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact same
way. Each eval takes place in its own environment and no bindings survive the
completion of the eval.
For ES6, non-strict evals of code containing only var or function
declarations must have exactly the ES5 behavior in order to maintain
compatibility. But what about eval code that contains new declaration forms
(let/const/class) exclusively or in combination with var/function
declarations? Three possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics if the eval code directly contains
any of the new declaration forms:
(function() {
eval(
var answer=42;
let forceSeprateEnvironment = true;
);
console.log(answer); // ReferenceError: answer is not defined
})();
3) Combination. use ES5 non-strict binding semantics for var/function
declarations but place let/const/class bindings into a per eval environment:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // ReferenceError: localToEval is not defined
)();
It would certainly be possible to specify #1, but I don't like it. Other than
for the global environment it would be cleaner if the new block scope-able
declarations were never dynamically added to the environment.
I think either #2 or #3 is plausible. #2 is a simpler story but introduces a
refactoring hazard. If you have some existing eval code that defines some
global functions or variables, then simply adding a let/const/class
declaration to the eval code ruins those global declarations.
I prefer the simplicity of #2, but I also worry about the WTF impact it might
have on evolving existing code.
Can we get away with #2, or are we going to have to go with #3? Are there
other alternatives?
Allen
___
es-discuss mailing list
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On Fri, Feb 14, 2014 at 1:34 AM, Mathias Bynens math...@qiwi.be wrote: Allen mentioned that `String#at` might not make it to ES6 because nobody in TC39 is championing it. I've now asked Rick if he would be the champion for this, and he agreed. (Thanks again!) Published to wiki here: http://wiki.ecmascript.org/doku.php?id=strawman:string_at Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
As far as I can see, your #4 and my #1 are exactly the same. How do you
think they differ?
Actually, on a second read, I don't think they are. I was perhaps more
explicit regarding strict mode, but I think the behavior there was already
clear enough to everyone. :)
On Fri, Feb 14, 2014 at 12:14 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
As far as I can see, your #4 and my #1 are exactly the same. How do you
think they differ?
Allen
On Feb 14, 2014, at 8:03 AM, Jeremy Martin wrote:
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically
considered a block, the let binding would survive past the completion of
the eval in non-strict mode:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // true
)();
(function() {
use strict;
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // ReferenceError: answer is not defined
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
I'm not necessarily arguing for that behavior, but weighing in since
that's the behavior I would have expected based on existing ES5
strict/non-strict/eval and ES6 let semantics...
On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical declaration
forms, but I hope the example from above will be evaluated in a new block.
See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug
report.
Goood point and this is something I need to specify in the next couple
weeks so let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new
environment that is immediately nested within the current
LexicalEnvironment. The scoping behavior is essentially the same as if the
eval code was the body of an iife that occurred at the same place as the
eval call. Bindings introduced by the eval code disappear after completion
of the eval.
In non-strict mode, each eval instantiates all declarations in the
current VariableEnvironment; that is the most immediately enclosing
function or global environment. Bindings introduced by the eval code
remain accessible from that VariableEnvironment after completion of the
eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact
same way. Each eval takes place in its own environment and no bindings
survive the completion of the eval.
For ES6, non-strict evals of code containing only var or function
declarations must have exactly the ES5 behavior in order to maintain
compatibility. But what about eval code that contains new declaration
forms (let/const/class) exclusively or in combination with var/function
declarations? Three possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics if the eval code directly
contains any of the new declaration forms:
(function() {
eval(
var answer=42;
let forceSeprateEnvironment = true;
);
console.log(answer); // ReferenceError: answer is not defined
})();
3) Combination. use ES5 non-strict binding semantics for var/function
declarations but place let/const/class bindings into a per eval environment:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
It would certainly be possible to specify #1, but I don't like it. Other
than for the global environment it would be cleaner if the new block
scope-able declarations were never dynamically added to the environment.
I think either #2 or #3 is plausible. #2 is a simpler story but
introduces a refactoring hazard. If you have some existing eval code that
defines some global functions or variables, then simply adding a
let/const/class declaration to the eval code ruins those global
declarations.
I prefer the simplicity of #2, but I also
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On Feb 14, 2014, at 1:34 AM, Mathias Bynens wrote: Allen mentioned that `String#at` might not make it to ES6 because nobody in TC39 is championing it. I’ve now asked Rick if he would be the champion for this, and he agreed. (Thanks again!) Looking over the ‘TC39 progress’ document at https://docs.google.com/a/chromium.org/document/d/1QbEE0BsO4lvl7NFTn5WXWeiEIBfaVUF7Dk0hpPpPDzU, it seems most of the work is already taken care of: the use case was discussed in this thread, the proposal has a complete spec text, and there’s an example implementation/polyfill with unit tests. See http://mths.be/at. Is there anything else I can do to help get this included as a non-TC39-member? But just to be even clear, the new feature gate for ES6 is officially closed. It's a really high bar to get over that closed gate. Unless the exclusion of a feature was a mistake, fixes a bug, or is somehow essentially to supporting something that is already in ES6 I don't think we should be talking about adding it to ES6. I don't think String.prototype.at fits any of those criteria. We've talked about it several times, including in the context of Norbert's original ES6 full unicode support proposal, and never achieved consensus on including it. Personally, I think it should be there but it's time to start talking about it for ES7 not ES6. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: System.import FTW
Thanks. I was missing the relationship between System and Loader somehow. So System.import is intended to be exactly the same as the import keyword (except promise-returning). That's good! Is there a way to do without the export keyword as well (I've heard rumors of anonymous exports but haven't named to track down a spec)? If so, it seems like as ES5 shim (not a full polyfill) could enable module authors to start tying into ES6 modules without corrupting their source with new keywords. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
1 or 3. We have already shot down similiar situations to 2 before. I don't
think it is worth bringing this up again.
1 is the least surprise. It is just bad practice, but so is eval and non
strict mode in the first place.
3 is fine if you think as if there was a block around the whole thing
(except for functions in block in non strict mode).
On Fri Feb 14 2014 at 1:42:13 PM, Jeremy Martin jmar...@gmail.com wrote:
As far as I can see, your #4 and my #1 are exactly the same. How do
you think they differ?
Actually, on a second read, I don't think they are. I was perhaps more
explicit regarding strict mode, but I think the behavior there was already
clear enough to everyone. :)
On Fri, Feb 14, 2014 at 12:14 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
As far as I can see, your #4 and my #1 are exactly the same. How do you
think they differ?
Allen
On Feb 14, 2014, at 8:03 AM, Jeremy Martin wrote:
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically
considered a block, the let binding would survive past the completion of
the eval in non-strict mode:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // true
)();
(function() {
use strict;
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // ReferenceError: answer is not defined
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
I'm not necessarily arguing for that behavior, but weighing in since
that's the behavior I would have expected based on existing ES5
strict/non-strict/eval and ES6 let semantics...
On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical declaration
forms, but I hope the example from above will be evaluated in a new block.
See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug
report.
Goood point and this is something I need to specify in the next couple
weeks so let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new
environment that is immediately nested within the current
LexicalEnvironment. The scoping behavior is essentially the same as if the
eval code was the body of an iife that occurred at the same place as the
eval call. Bindings introduced by the eval code disappear after completion
of the eval.
In non-strict mode, each eval instantiates all declarations in the current
VariableEnvironment; that is the most immediately enclosing function or
global environment. Bindings introduced by the eval code remain accessible
from that VariableEnvironment after completion of the eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact same
way. Each eval takes place in its own environment and no bindings survive
the completion of the eval.
For ES6, non-strict evals of code containing only var or function
declarations must have exactly the ES5 behavior in order to maintain
compatibility. But what about eval code that contains new declaration
forms (let/const/class) exclusively or in combination with var/function
declarations? Three possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics if the eval code directly
contains any of the new declaration forms:
(function() {
eval(
var answer=42;
let forceSeprateEnvironment = true;
);
console.log(answer); // ReferenceError: answer is not defined
})();
3) Combination. use ES5 non-strict binding semantics for var/function
declarations but place let/const/class bindings into a per eval environment:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
It would certainly be possible to specify #1, but I don't like it. Other
than for the global environment it would be
Re: eval of let, etc. Was: Re: restrictions on let declarations
On further reflection, #3 does feel like trying to rewrite the past. For
better or worse, non-strict mode allows declarations to persist past the
eval(). And while strict mode provides a license-to-kill on behavior like
that, I don't really see strong justification for that kind of surprise
factor for let in non-strict mode.
If you're not using strict mode AND you're using eval(), the damage is
arguably already done (or at least the danger already exists). Changing
the behavior of let in this case feels like removing an arbitrary* foot-gun
when we're already in the armory, so to speak.
* Granted it's not completely arbitrary, since `let` is new whereas `var`
is not, but hopefully you get my point...
On Fri, Feb 14, 2014 at 2:23 PM, Erik Arvidsson erik.arvids...@gmail.comwrote:
1 or 3. We have already shot down similiar situations to 2 before. I don't
think it is worth bringing this up again.
1 is the least surprise. It is just bad practice, but so is eval and non
strict mode in the first place.
3 is fine if you think as if there was a block around the whole thing
(except for functions in block in non strict mode).
On Fri Feb 14 2014 at 1:42:13 PM, Jeremy Martin jmar...@gmail.com wrote:
As far as I can see, your #4 and my #1 are exactly the same. How do
you think they differ?
Actually, on a second read, I don't think they are. I was perhaps more
explicit regarding strict mode, but I think the behavior there was already
clear enough to everyone. :)
On Fri, Feb 14, 2014 at 12:14 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
As far as I can see, your #4 and my #1 are exactly the same. How do you
think they differ?
Allen
On Feb 14, 2014, at 8:03 AM, Jeremy Martin wrote:
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically
considered a block, the let binding would survive past the completion of
the eval in non-strict mode:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // true
)();
(function() {
use strict;
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // ReferenceError: answer is not defined
console.log(localToEval); // ReferenceError: localToEval is
not defined
)();
I'm not necessarily arguing for that behavior, but weighing in since
that's the behavior I would have expected based on existing ES5
strict/non-strict/eval and ES6 let semantics...
On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical declaration
forms, but I hope the example from above will be evaluated in a new block.
See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug
report.
Goood point and this is something I need to specify in the next couple
weeks so let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new
environment that is immediately nested within the current
LexicalEnvironment. The scoping behavior is essentially the same as if the
eval code was the body of an iife that occurred at the same place as the
eval call. Bindings introduced by the eval code disappear after completion
of the eval.
In non-strict mode, each eval instantiates all declarations in the
current VariableEnvironment; that is the most immediately enclosing
function or global environment. Bindings introduced by the eval code
remain accessible from that VariableEnvironment after completion of the
eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact
same way. Each eval takes place in its own environment and no bindings
survive the completion of the eval.
For ES6, non-strict evals of code containing only var or function
declarations must have exactly the ES5 behavior in order to maintain
compatibility. But what about eval code that contains new declaration
forms (let/const/class) exclusively or in combination with var/function
declarations? Three possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On Fri, Feb 14, 2014 at 10:59 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Feb 14, 2014, at 1:34 AM, Mathias Bynens wrote: Allen mentioned that `String#at` might not make it to ES6 because nobody in TC39 is championing it. I've now asked Rick if he would be the champion for this, and he agreed. (Thanks again!) Looking over the 'TC39 progress' document at https://docs.google.com/a/chromium.org/document/d/1QbEE0BsO4lvl7NFTn5WXWeiEIBfaVUF7Dk0hpPpPDzU, it seems most of the work is already taken care of: the use case was discussed in this thread, the proposal has a complete spec text, and there's an example implementation/polyfill with unit tests. See http://mths.be/at. Is there anything else I can do to help get this included as a non-TC39-member? But just to be even clear, the new feature gate for ES6 is officially closed. It's a really high bar to get over that closed gate. Unless the exclusion of a feature was a mistake, fixes a bug, or is somehow essentially to supporting something that is already in ES6 I don't think we should be talking about adding it to ES6. I don't think String.prototype.at fits any of those criteria. We've talked about it several times, including in the context of Norbert's original ES6 full unicode support proposal, and never achieved consensus on including it. Personally, I think it should be there but it's time to start talking about it for ES7 not ES6. Yes, I absolutely agree, apologies as I realize that was not addressed in my previous message. Rick Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: System.import FTW
On Fri Feb 14 2014 at 2:20:07 PM, C. Scott Ananian ecmascr...@cscott.net wrote: Thanks. I was missing the relationship between System and Loader somehow. So System.import is intended to be exactly the same as the import keyword (except promise-returning). There is a big difference here. The syntax for import normalizes the name and then resolves the name relative to the current module. System.import only takes an already normalized name relative to the baseURL. So, you need to do the normalization and resolviong manually first. There was a proposal to have import do the normalizing and also take an optional referrerName. I'm afraid I don't remember what the outcome of that was. That's good! Is there a way to do without the export keyword as well (I've heard rumors of anonymous exports but haven't named to track down a spec)? There is a default export. It is just syntactic sugar over exporting and importing something with the name `default`. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: System.import FTW
(There is no spec on System, just rumors that it will be a predefined,
global instance of Loader).
As far I know the only way to use the es6 module loader without exports or
imports is to set values on 'this', the global object. I guess it's not
very different from using IIFE (function() { this.foo = 2; })(); vs a
module containing the body of the function.
On Fri, Feb 14, 2014 at 11:57 AM, Erik Arvidsson
erik.arvids...@gmail.comwrote:
On Fri Feb 14 2014 at 2:20:07 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
Thanks. I was missing the relationship between System and Loader somehow.
So System.import is intended to be exactly the same as the import keyword
(except promise-returning).
There is a big difference here. The syntax for import normalizes the name
and then resolves the name relative to the current module. System.import
only takes an already normalized name relative to the baseURL. So, you need
to do the normalization and resolviong manually first. There was a proposal
to have import do the normalizing and also take an optional referrerName.
I'm afraid I don't remember what the outcome of that was.
That's good! Is there a way to do without the export keyword as well
(I've heard rumors of anonymous exports but haven't named to track down a
spec)?
There is a default export. It is just syntactic sugar over exporting and
importing something with the name `default`.
___
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
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
I'm excited to start working on es7-shim once we get to that point! (String.prototype.at has a particularly simple shim, thankfully...) --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On Fri, Feb 14, 2014 at 12:23 PM, C. Scott Ananian ecmascr...@cscott.netwrote: I'm excited to start working on es7-shim once we get to that point! (String.prototype.at has a particularly simple shim, thankfully...) Have you seen: https://github.com/mathiasbynens/String.prototype.at ? Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: System.import FTW
erik: I'd be interested in learning the outcome of the normalization
discussion. As one of the maintainers of es6-shim I'm particularly
interested in ways to access ES6 features with ES5 syntax. If that
looks like:
```js
this['default'] = Promise.join(System.import('foo'),
System.import('bar')).spread(function(foo, bar) {
return { ... exports ... };
});
```
I can live with that. Any chance that we will accept and unwrap a
promise for the exported value? (Not that it really matters for the
above, since Promise.join will do recursive unwrapping, but it would
be nice for compatibility if this were transparent in general.)
john: yes, I suspected that System was underspecified. That's too bad.
--scott
On Fri, Feb 14, 2014 at 9:57 AM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
On Fri Feb 14 2014 at 2:20:07 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
Thanks. I was missing the relationship between System and Loader somehow.
So System.import is intended to be exactly the same as the import keyword
(except promise-returning).
There is a big difference here. The syntax for import normalizes the name
and then resolves the name relative to the current module. System.import
only takes an already normalized name relative to the baseURL. So, you need
to do the normalization and resolviong manually first. There was a proposal
to have import do the normalizing and also take an optional referrerName.
I'm afraid I don't remember what the outcome of that was.
That's good! Is there a way to do without the export keyword as well
(I've heard rumors of anonymous exports but haven't named to track down a
spec)?
There is a default export. It is just syntactic sugar over exporting and
importing something with the name `default`.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
yes, of course. es6-shim is a large-ish collection of such. However, it would be much better to use an implementation of `String#at` which used substr and thus avoided creating and appending a new string object. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Changing behavior of Array#copyWithin when used on array-like with negative length
For reference: https://bugs.ecmascript.org/show_bug.cgi?id=2546 `Array#copyWithin` has a (non-normative) signature of `(target, start, end = this.length)`. However, this is slightly misleading because the spec actually calls `ToLength` on `this.length` and then uses *that* for the default value of `end`. This changes `end`'s effective value when `this.length` is negative. In the bug we discuss changing the non-normative descriptive text to be less misleading. But I'd like to invite broader discussion on a different approach: can we change the spec so that the `end = this.length` default was actually correct? This would only possibly change behavior on array-likes with negative length, and probably wouldn't even change observable behavior in that case (since `length` is treated as 0). Basically we'd be just calling `ToInteger` on the default value of `end` rather than `ToLength`. But it would be an end-run around confusing language in the spec. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Changing behavior of Array#copyWithin when used on array-like with negative length
On Feb 14, 2014, at 12:46 PM, C. Scott Ananian wrote: For reference: https://bugs.ecmascript.org/show_bug.cgi?id=2546 `Array#copyWithin` has a (non-normative) signature of `(target, start, end = this.length)`. However, this is slightly misleading because the spec actually calls `ToLength` on `this.length` and then uses *that* for the default value of `end`. This changes `end`'s effective value when `this.length` is negative. In the bug we discuss changing the non-normative descriptive text to be less misleading. But I'd like to invite broader discussion on a different approach: can we change the spec so that the `end = this.length` default was actually correct? This would only possibly change behavior on array-likes with negative length, and probably wouldn't even change observable behavior in that case (since `length` is treated as 0). Basically we'd be just calling `ToInteger` on the default value of `end` rather than `ToLength`. But it would be an end-run around confusing language in the spec. --scott ToLength is used a number of places within the ES6 spec. where formerly ToUint32 was used. It allows indices to be larger 2^32-2 and avoids weird wrap behavior for indices in that range. I doubt that we could compatibly get away with replacing those legacy ToUnit32 calls with a ToLength that preserved negative values. Even if we could we would have to review all of the array (and string) algorithms that use ToLength to make sure they still work reasonably with negative length values. I really don't see what benefit we would get from that work. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
On Feb 14, 2014, at 11:38 AM, Jeremy Martin wrote: On further reflection, #3 does feel like trying to rewrite the past. For better or worse, non-strict mode allows declarations to persist past the eval(). And while strict mode provides a license-to-kill on behavior like that, I don't really see strong justification for that kind of surprise factor for let in non-strict mode. If you're not using strict mode AND you're using eval(), the damage is arguably already done (or at least the danger already exists). Changing the behavior of let in this case feels like removing an arbitrary* foot-gun when we're already in the armory, so to speak. * Granted it's not completely arbitrary, since `let` is new whereas `var` is not, but hopefully you get my point. Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Changing behavior of Array#copyWithin when used on array-like with negative length
On Feb 14, 2014, at 12:46 PM, C. Scott Ananian wrote: / For reference:https://bugs.ecmascript.org/show_bug.cgi?id=2546 // // `Array#copyWithin` has a (non-normative) signature of `(target, start, // end = this.length)`. However, this is slightly misleading because the // spec actually calls `ToLength` on `this.length` and then uses *that* // for the default value of `end`. This changes `end`'s effective value // when `this.length` is negative. // // In the bug we discuss changing the non-normative descriptive text to // be less misleading. // // But I'd like to invite broader discussion on a different approach: can // we change the spec so that the `end = this.length` default was // actually correct? This would only possibly change behavior on // array-likes with negative length, and probably wouldn't even change // observable behavior in that case (since `length` is treated as 0). // Basically we'd be just calling `ToInteger` on the default value of // `end` rather than `ToLength`. But it would be an end-run around // confusing language in the spec. // --scott / ToLength is used a number of places within the ES6 spec. where formerly ToUint32 was used. It allows indices to be larger 2^32-2 and avoids weird wrap behavior for indices in that range. I doubt that we could compatibly get away with replacing those legacy ToUnit32 calls with a ToLength that preserved negative values. Even if we could we would have to review all of the array (and string) algorithms that use ToLength to make sure they still work reasonably with negative length values. I really don't see what benefit we would get from that work. Allen I think Scott is requesting this change: https://gist.github.com/anba/6c75c34c72d4ffaa8de7 - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Changing behavior of Array#copyWithin when used on array-like with negative length
Le 14 févr. 2014 à 21:46, C. Scott Ananian ecmascr...@cscott.net a écrit : array-likes with negative length Array-likes with negative length doesn't make sense, or at least it isn't a useful concept as far as ECMAScript is concerned – as it doesn't make sense to consider arraylikes of fractional length, or of length equal to the string `LOL`. If the informal signature of `Array.prototype.copyWithin` is misleading, it could be rewritten as: Array.prototype.copyWithin (target, start, end = length of this) where length of `obj` is to be interpreted as `ToLength(obj.length)` – at least, it is what the algorithm uses in each and every step where the length is expected (the `len` variable in steps 8, 11, 12, 14 and 15). —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Changing behavior of Array#copyWithin when used on array-like with negative length
On Fri, Feb 14, 2014 at 11:50 AM, André Bargull andre.barg...@udo.edu wrote:
I think Scott is requesting this change:
https://gist.github.com/anba/6c75c34c72d4ffaa8de7
Yes, although my proposed diff (in the linked bug) was the shorter,
12. If end is undefined, let relativeEnd be ToInteger(lenVal); else
let
relativeEnd be ToInteger(end). Same effect, though.
Claude Pache wrote:
Array-likes with negative length doesn't make sense.
`Array.prototype.copyWithin.call({ length: -1 }, ... );`
Call it whatever you like, although I'm always interested in learning
new phrases of ECMAspeak (if there's an appropriate name for this).
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
On Fri, Feb 14, 2014 at 6:21 AM, Anne van Kesteren ann...@annevk.nl wrote: To be clear, we fixed this. And we will be going ahead and shipping promises in Firefox 29. Too many dependencies at this point to hold of longer. Since both Chrome and FIrefox have plans to support Promises, feel free to suggest any changes to `es6-shim` which would improve compatibility. It looks like that at the moment the `es6-shim` implementation is more spec-compliant than either of the shipping implementations? In particular, we support subclasses. At the moment we don't do any feature tests beyond does Promise exist in the global environment. For Map and Set we actually do some very specific bug-based tests to workaround old shipping implementations that aren't spec-compliant. So I'd also love to hear specifically about any bugs or missing features in your shipping implementation so that we can feature-test and workaround them. Finally, I have started `prfun` (https://github.com/cscott/prfun) as AFAIK the first es6-compatible promise package. That is, it assumes the presence of basic ES6 spec-compliant Promises and concentrates on adding features on top of that, using only the published API. It includes an implementation of `Promise.bind` using subclasses, in ES5-compatible syntax. It has a rather extensive test suite, borrowed from `bluebird`, `when`, and `q`. Feedback on `prfun` (including suggestions for better names!) is invited. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: System.import FTW
On Feb 14, 2014, at 12:09 PM, John Barton johnjbar...@google.com wrote: (There is no spec on System, just rumors that it will be a predefined, global instance of Loader). Rumors is a bit much. :) The notes do show the discussion but the resolution for some reason didn't get recorded. IIRC there was agreement that Reflect and System will both be globals (this has also been the general understanding for a long time, so it's nothing new). https://github.com/rwaldron/tc39-notes/blob/9ac398908394f9e2f8a1ac9b1e0c83952cd2f2fa/es6/2014-01/jan-28.md#spec-status-update Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: System.import FTW
On Fri, Feb 14, 2014 at 12:59 PM, David Herman dher...@mozilla.com wrote: https://github.com/rwaldron/tc39-notes/blob/9ac398908394f9e2f8a1ac9b1e0c83952cd2f2fa/es6/2014-01/jan-28.md#spec-status-update Yeah, I read that, and I thought the absence of a 'Resolution' was a bit suspicious. I thought there was a strong argument to export only one additional global, `Loader`, and to make the-instance-formerly-known-as-System available via `Loader`. I don't have a particular opinion here, but I will note that Java has a `System` class with very different semantics, so there may be some mental variable shadowing for some developers. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: System.import FTW
I don't think the details in System will be important, as you suggest there is not much to say. The critical issue is whether we will have access to an ES6 specified Loader class. The Loader class and System.fetch is enough I think to do any custom loader thing one wants. If we only have System then our customization options will be limited since we won't be able to call super methods. On Fri, Feb 14, 2014 at 2:59 PM, David Herman dher...@mozilla.com wrote: On Feb 14, 2014, at 12:09 PM, John Barton johnjbar...@google.com wrote: (There is no spec on System, just rumors that it will be a predefined, global instance of Loader). Rumors is a bit much. :) The notes do show the discussion but the resolution for some reason didn't get recorded. IIRC there was agreement that Reflect and System will both be globals (this has also been the general understanding for a long time, so it's nothing new). https://github.com/rwaldron/tc39-notes/blob/9ac398908394f9e2f8a1ac9b1e0c83952cd2f2fa/es6/2014-01/jan-28.md#spec-status-update Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Changing behavior of Array#copyWithin when used on array-like with negative length
Le 14 févr. 2014 à 23:40, C. Scott Ananian ecmascr...@cscott.net a écrit :
Claude Pache wrote:
Array-likes with negative length doesn't make sense.
`Array.prototype.copyWithin.call({ length: -1 }, ... );`
Call it whatever you like, although I'm always interested in learning
new phrases of ECMAspeak (if there's an appropriate name for this).
--scott
Since you are interested: The abstract operation ToLength converts its
argument to an integer suitable for use as the length of an array-like object.
[1]
It doesn't really matter whether ToLength could extract a reasonable value for
an unreasonable object, or not. But consistency is important: note that this
operation is used whenever the length of an arraylike is expected, not only for
default arguments.
[1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-tolength
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
Allen Wirfs-Brock wrote: the various forms of eval are already micro-mode, so I'm not sure if those points are very relevant. No, the various forms of eval do not have non-local effects of the kind your #2 did! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
Allen Wirfs-Brock wrote: On Feb 14, 2014, at 11:38 AM, Jeremy Martin wrote: On further reflection, #3 does feel like trying to rewrite the past. For better or worse, non-strict mode allows declarations to persist past the eval(). And while strict mode provides a license-to-kill on behavior like that, I don't really see strong justification for that kind of surprise factor for let in non-strict mode. If you're not using strict mode AND you're using eval(), the damage is arguably already done (or at least the danger already exists). Changing the behavior of let in this case feels like removing an arbitrary* foot-gun when we're already in the armory, so to speak. * Granted it's not completely arbitrary, since `let` is new whereas `var` is not, but hopefully you get my point. Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. +lots, this should be front of mind. In a block, we want the bindings local to that block to be statically analyzable. We want no non-local mode effects. So, #3 still wins. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
