Le 04/02/2012 01:14, John J Barton a écrit :
On Fri, Feb 3, 2012 at 3:14 PM, David Bruant bruan...@gmail.com wrote:
Le 03/02/2012 23:26, John J Barton a écrit :
On Fri, Feb 3, 2012 at 1:08 PM, David Bruant bruan...@gmail.com wrote:
I've been looking at Caja's code recently [1] and noticed that
Le 04/02/2012 04:42, Mark S. Miller a écrit :
Considering the 2-argument eval example from above, you could define a
'document' property is the second argument and this document
(what the
eval code gets when it asks for the document variable) could be an
emulation of an
On Fri, Feb 3, 2012 at 7:26 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Feb 3, 2012, at 4:26 PM, Jason Orendorff wrote:
On 2/3/12 6:13 PM, Allen Wirfs-Brock wrote:
But I also have to validly (and hopefully reasonably) specify exactly what
happens for the unrealistic use cases. There
On Fri, Feb 3, 2012 at 6:13 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Feb 3, 2012, at 12:44 PM, Jason Orendorff wrote:
It might also be useful to look at for(var ...;...;...) and for (...;...;...)
loops. Nobody is proposing changing the scoping for those, but they might
provide
On Sat, Feb 4, 2012 at 8:02 AM, Jason Orendorff
jason.orendo...@gmail.com wrote:
On Fri, Feb 3, 2012 at 7:26 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Under the scoping rules TC39 has agreed to, the initializer of a let/const
is always shadowed by the binding it is initializing[...]
On Feb 4, 2012, at 6:02 AM, Jason Orendorff wrote:
On Fri, Feb 3, 2012 at 7:26 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Feb 3, 2012, at 4:26 PM, Jason Orendorff wrote:
On 2/3/12 6:13 PM, Allen Wirfs-Brock wrote:
But I also have to validly (and hopefully reasonably) specify
On Feb 4, 2012, at 8:01 AM, Jason Orendorff wrote:
On Sat, Feb 4, 2012 at 8:02 AM, Jason Orendorff
jason.orendo...@gmail.com wrote:
On Fri, Feb 3, 2012 at 7:26 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Under the scoping rules TC39 has agreed to, the initializer of a let/const
is
On Sat, Feb 4, 2012 at 3:48 AM, David Bruant bruan...@gmail.com wrote:
[...]
The internalCompileExpr function uses with, how will this code behave in
ES6 since it's built on top of ES5 strict?
a) ES6 will still support non-strict code. An indirect ES6 eval (as used
here) will still eval
I want off this merry-go-round! Let's recap:
From the January 19th 2012 notes Waldemar took:
Discussion about scope of for-bindings.
for (var x = ...;;) {...} will, of course, retain ES1 semantics.
for (let x = ...;;) {...}
Allen: This will behave as in C++: x is bound once in a new scope
Le 04/02/2012 18:14, Mark S. Miller a écrit :
c) The ES6 module loader should make all these with-games unnecessary
anyhow, since it gives us a principled approach for controlling the
top level scope of untrusted code. Long term, this is the real answer.
Ok, good to know.
Can you show how
On Feb 4, 2012, at 9:49 AM, Brendan Eich wrote:
I want off this merry-go-round! Let's recap:
thanks for the recap...
...
From the January 19th 2012 notes Waldemar took:
Discussion about scope of for-bindings.
for (var x = ...;;) {...} will, of course, retain ES1 semantics.
for (let
Brendan Eich wrote:
$loopEnd: {
let d1 = e1, ... dN = eN;
if (cond) {
body;
update;
const $loop = { |d1, ... dN|
if (!cond) break $loopEnd;
body;
update;
$loop(d1, ... dN);
}
$loop(d1, ... dN);
}
}
Notes:
* ... is
ES5's existing array extras make working with arrays a joy.
However, sometimes arrays are not the right tool for the job. Perhaps you want
lazy evaluation semantics (generators). Or perhaps you want to communicate that
the list is immutable (compare .NET's `IEnumerableT` or Java's
Allen Wirfs-Brock wrote:
On Feb 4, 2012, at 9:49 AM, Brendan Eich wrote:
I agree we want to capture the first-iteration bindings in any
closures in those declarators' initializers.
It isn't clear to me why capture first-iteration is abstractly any
better than capture a hidden second x. In
Sorry for the resend. Meant to include the list.
I like this idea a lot! However, what would be the correct behavior of
a method like 'every' on an infinite generator?
-Michael A. Smith
On Fri, Feb 3, 2012 at 3:54 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
ES5's existing array
I'd say every and other methods like that should take another argument
that specifies the number if times to test.
You could say that every returns:
- true if the generator is finite and the function always returned true
- false if one of the finite (either because the generator is or
because a
It looks to me that all those schemes and desugaring are very
complicated. What is bad with scenario of reusing the same variable and
isolating it as local only for the async closures?
The code:
for (let a=..., b=..., otherInit; cond; update) {
// use a, b and things from otherInit
}
On Feb 4, 2012, at 12:55 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
On Feb 4, 2012, at 9:49 AM, Brendan Eich wrote:
I agree we want to capture the first-iteration bindings in any closures in
those declarators' initializers.
It isn't clear to me why capture first-iteration is
I'd say every and other methods like that should take another argument that
specifies the number if times to test.
This seems reasonable. Preferably that parameter would be optional, since the
majority of the time my iterators will not be derived from infinite generators
(and I know this).
Herby Vojčík wrote:
It looks to me that all those schemes and desugaring are very
complicated.
And what you showed isn't complicated? LOL.
What you're sketching is an optimization, one I believe Chez Scheme and
other implementations perform. Indeed any good implementation will
optimize
Has anyone checked out or used
http://docs.python.org/py3k/library/itertools.html ? Seems worth
considering since ES6 generators are derived from Python generators.
Indeed, there's no way to detect an infinite generator ahead of time.
Some array extras do not make sense even for very large
On a related note, there are many ways in which some of these methods
would overlap with the capabilities of array comprehensions and
generator expressions. As far as I can tell, the one thing you cannot
do (with, say, map) is take an array as input and process it lazily.
For example:
someVeryLargeArray.iMap(someFunction); // Lazy, guaranteed only to be iterable
How about `someVeryLargeArray.asIterator().map(someFunction)`?
-Domenic
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Allen Wirfs-Brock wrote:
On Feb 4, 2012, at 12:55 PM, Brendan Eich wrote:
The argument is as follows:
for (let i = 0, a = some.array, n = a.length; i n; i++) { ... }
here we definitely want the a in a.length (n's initializer) to be scoped by the head let -- to be the a declared
Brendan Eich wrote:
I agree we want to capture the first-iteration bindings in any closures in
those declarators' initializers.
This requires unrolling the loop once. Let's see how the desugaring from:
[snip]
For what it's worth, I agree with Mark's (2008) and Brendan's
desugarings and hereby
Herby Vojčík wrote:
It looks to me that all those schemes and desugaring are very complicated
The full problem is complicated, so that's to be expected.
What is bad with scenario of reusing the same variable and isolating it as
local only for the async closures?
Your proposal depends on
On Sat, Feb 4, 2012 at 1:02 PM, David Bruant bruan...@gmail.com wrote:
Le 04/02/2012 18:14, Mark S. Miller a écrit :
c) The ES6 module loader should make all these with-games unnecessary
anyhow, since it gives us a principled approach for controlling the
top level scope of untrusted code. Long
27 matches
Mail list logo
