Re: Maps and Sets, goodbye polyfill ?!
Brian Di Palma wrote: OK. So we have reached Peak JavaScript then. It's risky to assume anything like that based on past trends in optimizations and workloads. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maps and Sets, goodbye polyfill ?!
Andreas Rossberg wrote: Yes, VMs do a lot to handle these cases well, and e.g. produce a flat object representation for such examples. But like with all those optimisations they are just optimistic, you still need to guard all over the place, because JavaScript semantics is rather deprived of useful invariants. There is very little that provably holds for a larger region of code or for a non-trivial extend of object life time. So you get tons of repetitive checks even in optimised code. That's one way to do it. Another is to invalidate more aggressively optimized, less-guarded code when the unlikely bad thing happens. Classes won't improve performance because they don't introduce any new invariants either. They are just sugar. Right, although the const class or sealed class idea is still on the ES7 agenda. Struct types (see the binary data proposal) have far more potential on that front, as is already utilised in practice with typed arrays vs conventional JS arrays. Indeed, this is where Emscripten with appropriate optimization on the target VM side is getting within 1.2x of native (and not done yet) Like it or not, high-performance JavaScript will have to be far less dynamic and far more typed than what the language allows. ;) You mean what current editions allow without resorting to typed arrays. What's stopping future editions from adding sealed classes, struct syntax, whatever it takes? The final battle will be checked (real, not warning-only) type annotations. I'm not holding my breath after ES4, but who knows? My point here is JS evolves. It's not always easy to extend, but the alternatives look much harder. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maps and Sets, goodbye polyfill ?!
2013/7/15 Brendan Eich bren...@mozilla.com Andreas Rossberg wrote: Yes, VMs do a lot to handle these cases well, and e.g. produce a flat object representation for such examples. But like with all those optimisations they are just optimistic, you still need to guard all over the place, because JavaScript semantics is rather deprived of useful invariants. There is very little that provably holds for a larger region of code or for a non-trivial extend of object life time. So you get tons of repetitive checks even in optimised code. That's one way to do it. Another is to invalidate more aggressively optimized, less-guarded code when the unlikely bad thing happens. What is the expected improvements from const/sealed classes against such a strategy? Same question for checked type annotation? (are type annotation a form of userland guard?) Unrelated, but I'm curious: What do engines do when they face an object-as-map (random and potentially numerous keys)? Do they try to find a shape/hidden class and give up after realizing that the object really isn't stable? Do you have stats (I also take guesstimates) on how often object-as-map occur against class-ed objects? Will the use of ES6 maps to replace object-as-map make a significant dfference as far as perf is concerned? Thanks, David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: new Symbol(obj)
(a === b) = (new Symbol(a) === new Symbol(b)) Not sure I follow... so, I either I don't agree or I don't understand :). I'm having to dig deep to remember my math vocab here, but I think it may be most correct to say that the Symbol constructor, when passed an argument, should be injective [1]. That is, 1. let *F* = *new Symbol* 2. if http://en.wikipedia.org/wiki/Material_conditional *a* = *b*, then *F *(*a**)* = *F(b)* 3. if *a* != *b*, then *F(a) *!= *F(b)* In any case, I'd also say that weak maps are good enough for your use case. In some (most?) cases, but not all. There's already a consensus that the garbage collection semantics of WeakMaps aren't always appropriate [2]. By parameterizing the Symbol constructor, developers can create custom map/set types without the overhead of a Symbol Factory (as previously suggested by Allen). I believe this would be a useful building block for interesting and innovative custom types. [1]: https://en.wikipedia.org/wiki/Injective_function#Definition [2]: http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets On Mon, Jul 15, 2013 at 5:52 AM, Andreas Rossberg rossb...@google.comwrote: On 12 July 2013 22:29, Jeremy Martin jmar...@gmail.com wrote: My expectation would be that... (a === b) === (new Symbol(a) === new Symbol(b)) Nit: you probably either mean (a === b) = (new Symbol(a) === new Symbol(b)) or (Object.is(a, b)) === (new Symbol(a) === new Symbol(b)) In any case, I'd also say that weak maps are good enough for your use case. /Andreas -- 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: Proposal: new Symbol(obj)
so, I either I don't agree or I don't understand It was the latter - I understand and agree now :) On Mon, Jul 15, 2013 at 10:03 AM, Andreas Rossberg rossb...@google.comwrote: On 15 July 2013 15:49, Jeremy Martin jmar...@gmail.com wrote: (a === b) = (new Symbol(a) === new Symbol(b)) Not sure I follow... so, I either I don't agree or I don't understand :). I'm having to dig deep to remember my math vocab here, but I think it may be most correct to say that the Symbol constructor, when passed an argument, should be injective [1]. That is, 1. let F = new Symbol 2. if a = b, then F(a) = F(b) 3. if a != b, then F(a) != F(b) I agree, but the problem is that JavaScript's === is not an equivalence relation, due to the dreaded NaN !== NaN that IEEE invented in some delirium. So you cannot define injectivity based on it. You merely get an implication for the above, which is what the = was supposed to encode. Object.is OTOH implements a proper equivalence relation, i.e. a = in the mathematical sense. It only differs from === by having a sane semantics for NaN. But as I said, I was merely picking a nit. /Andreas -- 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: Unlimited Integers (was: more numeric constants please (especially EPSILON))
From: Brendan Eich [bren...@mozilla.com] No wrapping object type -- those are legacy, to be avoided. See http://wiki.ecmascript.org/doku.php?id=strawman:value_objects. The main thing is value not reference semantics. Hmm, is `0UL.toString()` not possible then? What about `0UL + `? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
s === Object(s) This should throw a TypeError. In the case of a Symbol, `Object(*value*)` results in `ToObject(*value*)` [1]. And, in the case of Symbol, ToObject should throw a TypeError [2]. [1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.2.1.1 [2] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-9.1.9 On Mon, Jul 15, 2013 at 10:48 AM, Mark S. Miller erig...@google.com wrote: Given that s is a Symbol and b is a Bignum, is s === Object(s) ? Is b === Object(b) ? The reason I ask is that x === Object(x) is often used to distinguish primitive values from objects. The other thing that's often used is typeof, but these uses of typeof usually assume that the full range of possible answers is already known. If we're going to be expanding the typeof answers, then we need guidance on how to write this test now (es5) such that it stays robust. -- Cheers, --MarkM ___ 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
generators vs forEach
[prompted by this nodejs list thread Weird error with generators (using suspend or galaxy) https://groups.google.com/forum/#!topic/nodejs/9omOdgSPkz4 ] 1. higher order functions are used to model control structures 2. generators/yield are designed to allow for suspend/resume of control structure code These two statements come in conflict if one considers the restriction that generators be based on flat continuations, which is sufficient to span built-in control structures like for but not predefined control structures like forEach. The support for nested generators (yield*) differs from normal function call operation. I have not seen this conflict discussed here, so I wanted to raise it in case it was an oversight and something can be done about it. As far as I can tell, there are two issues: - current predefined operations like forEach, map, filter, .. are not fully integrated with generators, even though they model synchronous operations; expecting users to duplicate their functionality for use with generators seems wrong; - is it even possible to define higher-order operations that can be used both normally (without yield inside their callbacks, without yield wrapping their result) and with generators (with yield inside their callbacks, with yield wrapping their result)? Claus http://clausreinke.github.com/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
Allen (cc-ed) changed symbols back to objects in draft rev 16 (https://bugs.ecmascript.org/show_bug.cgi?id=1546#c2), so I guess Object(x) will still work in ES6 to test for object types. - André I see. That's unpleasant. In ES5, Object(x) can never throw, and so the code paths using |x === Object(x)| are not prepared for a throw. Much old code will break. On Mon, Jul 15, 2013 at 8:01 AM, Jeremy Martin jmar777 at gmail.com https://mail.mozilla.org/listinfo/es-discuss wrote: / s === Object(s) // // This should throw a TypeError. In the case of a Symbol, `Object(*value*)` // results in `ToObject(*value*)` [1]. And, in the case of Symbol, ToObject // should throw a TypeError [2]. // // [1]http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.2.1.1 http://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-15.2.1.1 // [2]http://people.mozilla.org/~jorendorff/es6-draft.html#sec-9.1.9 http://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-9.1.9 // // On Mon, Jul 15, 2013 at 10:48 AM, Mark S. Miller erights at google.com https://mail.mozilla.org/listinfo/es-discusswrote: // // Given that s is a Symbol and b is a Bignum, is // // s === Object(s) // // ? // // Is // // b === Object(b) // // ? // // The reason I ask is that x === Object(x) is often used to distinguish // primitive values from objects. The other thing that's often used is typeof, // but these uses of typeof usually assume that the full range of possible // answers is already known. If we're going to be expanding the typeof // answers, then we need guidance on how to write this test now (es5) such // that it stays robust. // // // -- // Cheers, // --MarkM// https://mail.mozilla.org/listinfo/es-discuss // // // -- // Jeremy Martin // 661.312.3853 // http://devsmash.com // @jmar777 // / -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
That's unpleasant. [...] Much old code will break.
Indeed. I hadn't actually noticed that change until just now. It looks
like ES6 code can take advantage of Object.isObject(), which seems to
delegate the work to Type(*x*) [1]. It wasn't overwhelmingly clear to me,
but I would assume `Object.isObject('foo') === false` and
`Object.isObject(new String('foo')) === true`.
Has anyone surveyed/looked into what the fallout of throwing on stuff like
`Object(undefined)` will be?
[1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-8
On Mon, Jul 15, 2013 at 11:09 AM, Mark S. Miller erig...@google.com wrote:
I see. That's unpleasant. In ES5, Object(x) can never throw, and so the
code paths using |x === Object(x)| are not prepared for a throw. Much old
code will break.
On Mon, Jul 15, 2013 at 8:01 AM, Jeremy Martin jmar...@gmail.com wrote:
s === Object(s)
This should throw a TypeError. In the case of a Symbol, `Object(*value*)`
results in `ToObject(*value*)` [1]. And, in the case of Symbol,
ToObject should throw a TypeError [2].
[1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.2.1.1
[2] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-9.1.9
On Mon, Jul 15, 2013 at 10:48 AM, Mark S. Miller erig...@google.comwrote:
Given that s is a Symbol and b is a Bignum, is
s === Object(s)
?
Is
b === Object(b)
?
The reason I ask is that x === Object(x) is often used to distinguish
primitive values from objects. The other thing that's often used is typeof,
but these uses of typeof usually assume that the full range of possible
answers is already known. If we're going to be expanding the typeof
answers, then we need guidance on how to write this test now (es5) such
that it stays robust.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
--
Cheers,
--MarkM
--
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: How primitive are Symbols? Bignums? etc
Ahh, thanks. Somehow I read that as `Object(undefined)` -
ObjectCreate(undefined)` - throw, but that's not the case.
On Mon, Jul 15, 2013 at 11:39 AM, Mark S. Miller erig...@google.com wrote:
Object(undefined) would still not throw:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.2.1.1 step 1
On Mon, Jul 15, 2013 at 8:37 AM, Jeremy Martin jmar...@gmail.com wrote:
That's unpleasant. [...] Much old code will break.
Indeed. I hadn't actually noticed that change until just now. It looks
like ES6 code can take advantage of Object.isObject(), which seems to
delegate the work to Type(*x*) [1]. It wasn't overwhelmingly clear to
me, but I would assume `Object.isObject('foo') === false` and
`Object.isObject(new String('foo')) === true`.
Has anyone surveyed/looked into what the fallout of throwing on stuff
like `Object(undefined)` will be?
[1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-8
On Mon, Jul 15, 2013 at 11:09 AM, Mark S. Miller erig...@google.comwrote:
I see. That's unpleasant. In ES5, Object(x) can never throw, and so the
code paths using |x === Object(x)| are not prepared for a throw. Much old
code will break.
On Mon, Jul 15, 2013 at 8:01 AM, Jeremy Martin jmar...@gmail.comwrote:
s === Object(s)
This should throw a TypeError. In the case of a Symbol, `Object(*value
*)` results in `ToObject(*value*)` [1]. And, in the case of Symbol,
ToObject should throw a TypeError [2].
[1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.2.1.1
[2] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-9.1.9
On Mon, Jul 15, 2013 at 10:48 AM, Mark S. Miller erig...@google.comwrote:
Given that s is a Symbol and b is a Bignum, is
s === Object(s)
?
Is
b === Object(b)
?
The reason I ask is that x === Object(x) is often used to distinguish
primitive values from objects. The other thing that's often used is
typeof,
but these uses of typeof usually assume that the full range of possible
answers is already known. If we're going to be expanding the typeof
answers, then we need guidance on how to write this test now (es5) such
that it stays robust.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
--
Cheers,
--MarkM
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
--
Cheers,
--MarkM
--
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: Language Negotiation API
As for LookupAvailableLocales, there might be a problem with Zbigniew's vision of it as any tags would be returned without extensions. I'm not sure if this is something that we'd need to worry about, though. No, that's good, because locales will be stored under names without them as well. Cheers, zb. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Unlimited Integers (was: more numeric constants please (especially EPSILON))
Mark S. Miller wrote: On Sun, Jul 14, 2013 at 10:39 PM, Brendan Eich bren...@mozilla.com mailto:bren...@mozilla.com wrote: Mark S. Miller wrote: First, I wholeheartedly agree. JS is increasingly being used as a target of compilation. When I asking people doing so what they biggest pain point is, the lack of support for integers is often the first thing mentioned. int64/uint64 come up faster when compiling from C/C++. I've prototyped these in SpiderMonkey in a patch that I'm still rebasing, but planning to land pretty soon: https://bugzilla.mozilla.org/show_bug.cgi?id=749786 I don't think we should introduce precision limited integers into JS, ever. The only point would be to do something weird on overflow of the precision limit. The traditional C-like weirdness is wrapping -- the only advantage being that it avoids even needing to check for overflow. We already have precision limited integers in JS, both via the bitwise-logical and shift operators, and via typed arrays / binary data. We need 64-bit ints for the latter, scalar and SIMD-vector as well as arbitrary length typed array element type. This ship has sailed, bignums are not equivalent or a superset. These are in the hardware, they need to be in JS for the memory safe low-road role it plays for WebGL, asm.js, etc. Were we not introducing TypedArrays until ES7, would we have typedArray.length be a bignum rather than a floating point number? If so, is there anything we can do in ES6 to leave ourselves this option in ES7? That would be unwanted, overkill. All typed arrays want is memory capacity, and 64 bits is more than enough. Even 53 is enough, and that's where ES6 is going, last I talked to Allen. People do want 4MB typed arrays. When a bignum represents a small integer, there's no reason that it needs to be any slower than a JS floating point number representing a small integer. Most JS implementations already optimize the latter to store the small integer in the pointer with a tag indicating that the non-tag bits are the small integer value. Exactly the same trick has been used for bignums in Lisps and Smalltalks for many decades. Sure, I'm familiar -- but again those older implementations did not face the performance constraints of the low road that JS does, nor were they were quite so aggressively optimized. I'm not saying bignums couldn't be used as doubles are today -- they could. Rather, JS has number and always will, and the speculations toward int are sunk cost (good sunk cost in a practical sense). Waiting for bignums to come in before typed arrays, just to support types bigger than memory in any foreseeable future, and get the same optimizations as number, does not fly. We won't wait in ES6 -- we will be lucky to get integer-domain double instead of uint32 lengths for typed arrays if not arrays. As long as the numbers represent small integers, I think the only differences would be semantics, not performance. Both, in the short run, in practice. But we aren't even doing bignums in ES6, and we are doing typed arrays / binary data. We need to satisfy 4G memory buffer use cases now, and be future-proof. 53 bits is enough. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Unlimited Integers (was: more numeric constants please (especially EPSILON))
Domenic Denicola wrote: From: Brendan Eich [bren...@mozilla.com] No wrapping object type -- those are legacy, to be avoided. See http://wiki.ecmascript.org/doku.php?id=strawman:value_objects. The main thing is value not reference semantics. Hmm, is `0UL.toString()` not possible then? What about `0UL + `? Of course those are possible -- int64 and uint64 are value *objects*, as I shows last message: js i = -1L -1L js i === int64(-1) true js u = 0UL 0UL js u = ~u 18446744073709551615UL js u.toString(16) There's no mutable Int64 or Uint64 wrapper, that's the point. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Unlimited Integers (was: more numeric constants please (especially EPSILON))
On Jul 15, 2013, at 8:15 AM, Mark S. Miller erig...@google.com wrote: No wrapping object type -- those are legacy, to be avoided. See http://wiki.ecmascript.org/doku.php?id=strawman:value_objects. The main thing is value not reference semantics. On that page: It’s forwards-compatible with future mechanisms for user-defined value objects. How can we be confident of this? I would like to be. That's a concern I have as well -- i'm not 100% sold on user-defined value objects, but i think i'd prefer that we get those done before bolting on [u]int64 and hoping that they're forwards compatible. I don't want to deal with any we can't do x due to uint64 style problems. --Oliver ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: generators vs forEach
Alternatively, could `yield` simply be lexically bound to the nearest
GeneratorFunction scope, rather than the nearest Function?
E.g., instead of:
suspend(function* (resume) {
yield setTimeout(resume, 1000);
console.log('foo');
yield setTimeout(resume, 1000);
console.log('bar');
})();
... we could write:
suspend(function* (resume) {
['foo', 'bar'].forEach(function(word) {
yield setTimeout(resume, 1000);
console.log(word);
});
})();
The current state of things here is pretty ugly, and I'd really like to
avoid having to add something like `suspend.forEach(Array,
GeneratorFunction)` with `yield*` in the body.
On Mon, Jul 15, 2013 at 11:33 AM, Claus Reinke claus.rei...@talk21.comwrote:
[prompted by this nodejs list thread Weird error with generators (using
suspend or galaxy)
https://groups.google.com/**forum/#!topic/nodejs/**9omOdgSPkz4https://groups.google.com/forum/#!topic/nodejs/9omOdgSPkz4]
1. higher order functions are used to model control structures
2. generators/yield are designed to allow for suspend/resume
of control structure code
These two statements come in conflict if one considers the restriction
that generators be based on flat continuations, which is sufficient to
span built-in control structures like for but not predefined control
structures like forEach. The support for nested generators (yield*)
differs from normal function call operation.
I have not seen this conflict discussed here, so I wanted to raise it
in case it was an oversight and something can be done about it. As
far as I can tell, there are two issues:
- current predefined operations like forEach, map, filter, ..
are not fully integrated with generators, even though they
model synchronous operations; expecting users to duplicate
their functionality for use with generators seems wrong;
- is it even possible to define higher-order operations that can be
used both normally (without yield inside their callbacks, without
yield wrapping their result) and with generators (with yield
inside their callbacks, with yield wrapping their result)?
Claus
http://clausreinke.github.com/
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://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: Proposal: new Symbol(obj)
On Jul 15, 2013, at 6:49 AM, Jeremy Martin wrote: In some (most?) cases, but not all. There's already a consensus that the garbage collection semantics of WeakMaps aren't always appropriate [2]. By parameterizing the Symbol constructor, developers can create custom map/set types without the overhead of a Symbol Factory (as previously suggested by Allen). I believe this would be a useful building block for interesting and innovative custom types. [1]: https://en.wikipedia.org/wiki/Injective_function#Definition [2]: http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets An implementation of your proposal is going to have to have to internally use some wort of weak-keyed table, in practice an implementation would probably use the same GC mechanisms that are there to support WeakMap. So, I doubt there would be much performance difference between a built-in and a roll-your-own implementation. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: generators vs forEach
I believe duplicating the `Array.prototype` built-ins as generator versions, in user-code, is the expected path forward. Perhaps an itertools-like module will be standardized and added in ES7, after that cowpath has been paved. This pain is somewhat alleviated by generator expressions (which cover filter and map) and `for`-`of` (which covers the rest, more manually). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
On Jul 15, 2013, at 8:35 AM, André Bargull wrote: Allen (cc-ed) changed symbols back to objects in draft rev 16 (https://bugs.ecmascript.org/show_bug.cgi?id=1546#c2), so I guess Object(x) will still work in ES6 to test for object types. Correct, Symbols as primitive values were just causing too many issues. Essentially, everyplace in the spec. that needs an object had to be updated to explicit deal with Symbols. That certainly isn't a pattern we want to follow in the future if add new value types such as bignums. It's much cleaner to freeze the set of primitive types and make all future value types (including Symbols) objects. just as it would have been even cleaner if everything was an object and there were not primitive types. Regarding, typeof. The right way to look at it is that the set of results that correspond to non-object types will be fixed and includes only (undefined, null, number, string, boolean). All other typeof values correspond of objects (where an object is a value that support the ES internal MOP). Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Unlimited Integers (was: more numeric constants please (especially EPSILON))
Oliver Hunt wrote: On Jul 15, 2013, at 8:15 AM, Mark S. Miller erig...@google.com mailto:erig...@google.com wrote: No wrapping object type -- those are legacy, to be avoided. See http://wiki.ecmascript.org/doku.php?id=strawman:value_objects. The main thing is value not reference semantics. On that page: It’s forwards-compatible with future mechanisms for user-defined value objects. How can we be confident of this? I would like to be. That's a concern I have as well -- i'm not 100% sold on user-defined value objects, but i think i'd prefer that we get those done before bolting on [u]int64 and hoping that they're forwards compatible. I don't want to deal with any we can't do x due to uint64 style problems. Totally -- that's why all of this is on the ES7 agenda. I'll write a strawman on user-defined value objects. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
On Mon, Jul 15, 2013 at 12:24 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Jul 15, 2013, at 8:35 AM, André Bargull wrote: Allen (cc-ed) changed symbols back to objects in draft rev 16 ( https://bugs.ecmascript.org/show_bug.cgi?id=1546#c2), so I guess Object(x) will still work in ES6 to test for object types. Correct, Symbols as primitive values were just causing too many issues. Essentially, everyplace in the spec. that needs an object had to be updated to explicit deal with Symbols. That certainly isn't a pattern we want to follow in the future if add new value types such as bignums. It's much cleaner to freeze the set of primitive types and make all future value types (including Symbols) objects. just as it would have been even cleaner if everything was an object and there were not primitive types. Regarding, typeof. The right way to look at it is that the set of results that correspond to non-object types will be fixed and includes only (undefined, null, number, string, boolean). All other typeof values correspond of objects (where an object is a value that support the ES internal MOP). I'm very surprised to see null in this list, and not function -- a typeof typo I hope? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
On Jul 15, 2013, at 9:35 AM, Dean Landolt wrote: On Mon, Jul 15, 2013 at 12:24 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Regarding, typeof. The right way to look at it is that the set of results that correspond to non-object types will be fixed and includes only (undefined, null, number, string, boolean). All other typeof values correspond of objects (where an object is a value that support the ES internal MOP). I'm very surprised to see null in this list, and not function -- a typeof typo I hope? Sorry, null should be in the list, and is the one legacy value that muddles typeof. functions are objects, not primitive values. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
On Jul 15, 2013, at 9:38 AM, Mark S. Miller wrote: typeof x === 'function' and typeof x === 'object' are the current indications of non-primitive types. What Allen is saying is that this set may expand, but the typeof answers that indicate primitive value types will not. Allen was enumerating the non-expanding set of primitive-value answers. Yes, this better expresses what I meant ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: generators vs forEach
Correct me if I'm wrong, but wouldn't the lexical-scoping restraint satisfy
the shallow generator requirement? As I understand it, the issue with deep
generators and CPS transformations is that the transformations have to be
applied to functions that aren't even lexically inside the
GeneratorFunction. Additionally, can't the nested CPS transformations
issue by alleviated with a reference to the GeneratorFunction stack frame
itself (a la SpiderMonkey)?
On Mon, Jul 15, 2013 at 12:45 PM, Mark S. Miller erig...@google.com wrote:
This would make generators deep, violating the non-interleaving
assumptions of intermediate callers on the call stack. This is why we
accepted generators only on condition that they be shallow. We knew at the
time that this privileges built-in control structures over user defined
ones. The alternative would have been to omit generators completely. We
agree that shallow generators were worth it, despite this non-uniformity.
Put another way, shallow generators are equivalent to a local cps
transform of the generator function itself. Deep generators would require
the equivalent of CPS transforming the world -- violating the stateful
assumptions of existing code.
On Mon, Jul 15, 2013 at 9:09 AM, Jeremy Martin jmar...@gmail.com wrote:
Alternatively, could `yield` simply be lexically bound to the nearest
GeneratorFunction scope, rather than the nearest Function?
E.g., instead of:
suspend(function* (resume) {
yield setTimeout(resume, 1000);
console.log('foo');
yield setTimeout(resume, 1000);
console.log('bar');
})();
... we could write:
suspend(function* (resume) {
['foo', 'bar'].forEach(function(word) {
yield setTimeout(resume, 1000);
console.log(word);
});
})();
The current state of things here is pretty ugly, and I'd really like to
avoid having to add something like `suspend.forEach(Array,
GeneratorFunction)` with `yield*` in the body.
On Mon, Jul 15, 2013 at 11:33 AM, Claus Reinke
claus.rei...@talk21.comwrote:
[prompted by this nodejs list thread Weird error with generators (using
suspend or galaxy)
https://groups.google.com/**forum/#!topic/nodejs/**9omOdgSPkz4https://groups.google.com/forum/#!topic/nodejs/9omOdgSPkz4]
1. higher order functions are used to model control structures
2. generators/yield are designed to allow for suspend/resume
of control structure code
These two statements come in conflict if one considers the restriction
that generators be based on flat continuations, which is sufficient to
span built-in control structures like for but not predefined control
structures like forEach. The support for nested generators (yield*)
differs from normal function call operation.
I have not seen this conflict discussed here, so I wanted to raise it
in case it was an oversight and something can be done about it. As
far as I can tell, there are two issues:
- current predefined operations like forEach, map, filter, ..
are not fully integrated with generators, even though they
model synchronous operations; expecting users to duplicate
their functionality for use with generators seems wrong;
- is it even possible to define higher-order operations that can be
used both normally (without yield inside their callbacks, without
yield wrapping their result) and with generators (with yield
inside their callbacks, with yield wrapping their result)?
Claus
http://clausreinke.github.com/
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://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
--
Cheers,
--MarkM
--
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: How primitive are Symbols? Bignums? etc
On Jul 15, 2013, at 9:40 AM, Andreas Rossberg wrote: On 15 July 2013 18:24, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jul 15, 2013, at 8:35 AM, André Bargull wrote: Allen (cc-ed) changed symbols back to objects in draft rev 16 (https://bugs.ecmascript.org/show_bug.cgi?id=1546#c2), so I guess Object(x) will still work in ES6 to test for object types. Correct, Symbols as primitive values were just causing too many issues. Oh. I wasn't aware of this. Is this just a spec language change, or is it a semantic change? If the latter, then I have to disagree with the change. The is primarily an internal spec. change. Many internal operations within the spec. require objects as parameters. This required inserting inserting explicit guards in p=many places within the specification and remembering to include them in new algorithms. At the March meeting you objected to the two pages of specification required to define Symbols as exotic objects. It turned out that those two pages were fair simpler and less intrusive than the all the individual spec. changes (and ongoing additions) that were needed to support symbols as primitive values. User visible semantics comes down to whether or not there is a Symbol wrapper object. As far as I can tell, tell from the notes, there was no consensus WRT Symbol wrappers record in March and when I tried to convert to Symbols as primitive values in the spec. I don't provide such wrappers. Instead, I made ToObject throw for symbols values. If you have wrapper objects, then you have visible semantics such as: let s = Symbol(); console.log(Object(s) === Object(s)); //false, because each call to Object produces a new wrapper object console(s === Object(s)); //false, because each call to Object produces a new wrapper object If you have symbols as primitive values, but no wrappers you get: console.log(Object(s) === Object(s)); //TypeError console(s === Object(s)); //TypeError If you have symbols as exotic objects you get: console.log(Object(s) === Object(s)); //true console(s === Object(s)); //true Because ES5 added auto-wrapping of primitive values within PutValue/GetValue, primitive values already act as if they were objects in most situations and except for the identify complications numbers/strings/booleans values can generally be used and reasoned about as if they were instances of Number/String/Boolean. We really should avoid adding new primitive types and wrapper objects. Value objects are the way to go, starting with Symbol. I'd be interested in hearing how this makes any difference to you from an implementation perspective. Even when symbols are specified as exotic objects you can still encode them as immediate values, just like you would a SmallInteger in Smalltalk. It's only when actual object MOP operations are applied to them that you should have to do any special casing but these are generally the same situations where you would have to auto-wrap primitive values. I would be interested in hearing if there are places in your implementation where specifying symbols as exotic objects will make an actual performance difference when using symbols as property keys. Essentially, everyplace in the spec. that needs an object had to be updated to explicit deal with Symbols. Allen, can you elaborate where symbols introduced cases that did not already have to be handled for other primitive types? Every place that did a ToObject, or equivalent. I'm pushing out a new spec. draft today or tomorrow and you can see the changes there. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
Allen Wirfs-Brock wrote: On Jul 15, 2013, at 8:35 AM, André Bargull wrote: Allen (cc-ed) changed symbols back to objects in draft rev 16 (https://bugs.ecmascript.org/show_bug.cgi?id=1546#c2), so I guess Object(x) will still work in ES6 to test for object types. Correct, Symbols as primitive values were just causing too many issues. Essentially, everyplace in the spec. that needs an object had to be updated to explicit deal with Symbols. That certainly isn't a pattern we want to follow in the future if add new value types such as bignums. It's much cleaner to freeze the set of primitive types and make all future value types (including Symbols) objects. just as it would have been even cleaner if everything was an object and there were not primitive types. +1. Regarding, typeof. The right way to look at it is that the set of results that correspond to non-object types will be fixed and includes only (undefined, null, number, string, boolean). All other typeof values correspond of objects (where an object is a value that support the ES internal MOP). (Regrets on lack of null typeof-result, of course.) I'm updating my int64/uint64 experimental patch to return int64 and uint64 typeof-types, to uphold these invariants: typeof x == typeof y x == y = x === y If typeof 0L and 0UL were object, this would fail, but we want 0L == 0UL. This came up with decimal in the ES5 era, where 0m == 0 but 0m !== 0. It's generally a problem, not just for 0 but for many pairs of numeric types subsuming a subset of the Integers where the values in common should equate by == but not ===. The (x === Object(x)) test evaluates to true for value objects in this proposal, though. This may break code looking for primitives but we need to see what such code expects. Is it filtering out the legacy typeof-result primitives (plus null), trying to find values for which typeof currently returns object or function? If so, I don't see a problem: int64, bignum, etc. are not legacy primitives. Is this test looking for objects that are their own wrappers? Again all is well, unless mutable wrapper is assumed -- but that's not safe in the ES5 era to assume, anyway. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: generators vs forEach
On 7/15/2013 10:24 AM, Jeremy Martin wrote:
Correct me if I'm wrong, but wouldn't the lexical-scoping restraint
satisfy the shallow generator requirement? As I understand it, the
issue with deep generators and CPS transformations is that the
transformations have to be applied to functions that aren't even
lexically inside the GeneratorFunction. Additionally, can't the
nested CPS transformations issue by alleviated with a reference to the
GeneratorFunction stack frame itself (a la SpiderMonkey)?
Consider the following:
function* yieldEach(array){
array.forEach(n = {
yield n;
});
}
In order for this to work, not only does `yieldEach` have to be
suspended for the inner yield, but forEach does as well. That means CPS
transforming functions based on whether they call a yielding function.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Language Negotiation API
Would you expect to support the same locales as Intl constructors in your library? Can you safely make that assumption? Canonicalisation makes sense because I would expect a library to canonicalise the tag and then try and load the file containing relevant data whether the native API supports it or not. Forgive me if I'm misunderstanding something, I didn't have a look at your project in great detail. Andy On 15 Jul 2013 16:49, Zbigniew Braniecki zbranie...@mozilla.com wrote: As for LookupAvailableLocales, there might be a problem with Zbigniew's vision of it as any tags would be returned without extensions. I'm not sure if this is something that we'd need to worry about, though. No, that's good, because locales will be stored under names without them as well. Cheers, zb. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: generators vs forEach
That means CPS transforming functions based on whether they call a
yielding function.
Well, yes :) Admittedly, that does seem messy. Not to sound defeatist,
but I'm sensing that I don't actually have the necessary knowledge to
further argue this. I'll just end with saying that it'll be unfortunate if
we're going to have to endure the clunkiness of nested generators anywhere
higher-order functions are called for. Regardless of whatever solutions
may or may not be appropriate, I at a minimum echo Claus' sentiment - it
seems like there's a nice opportunity here to improve the modeling of
control structures.
On Mon, Jul 15, 2013 at 3:01 PM, Brandon Benvie bben...@mozilla.com wrote:
On 7/15/2013 10:24 AM, Jeremy Martin wrote:
Correct me if I'm wrong, but wouldn't the lexical-scoping restraint
satisfy the shallow generator requirement? As I understand it, the issue
with deep generators and CPS transformations is that the transformations
have to be applied to functions that aren't even lexically inside the
GeneratorFunction. Additionally, can't the nested CPS transformations
issue by alleviated with a reference to the GeneratorFunction stack frame
itself (a la SpiderMonkey)?
Consider the following:
function* yieldEach(array){
array.forEach(n = {
yield n;
});
}
In order for this to work, not only does `yieldEach` have to be suspended
for the inner yield, but forEach does as well. That means CPS transforming
functions based on whether they call a yielding function.
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://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: Language Negotiation API
- Original Message - Would you expect to support the same locales as Intl constructors in your library? Yes. Can you safely make that assumption? I'd have to think more about edge cases, but my initial reaction is - yes. Canonicalisation makes sense because I would expect a library to canonicalise the tag and then try and load the file containing relevant data whether the native API supports it or not. Forgive me if I'm misunderstanding something, I didn't have a look at your project in great detail. There's no need to look at my project. All I'm asking is to talk about exposing the API for negotiating between locales provided by the application and locales requested by the user with the result being the list of available locales that the user wants sorted by the user preference. That enables us to load the locale 0 and fallback to locale 1 and then to locale 2 etc. The only crucial point here is that we need to operate on the list of available locales, not requested, because we will be selecting from the available ones. Cheers, g. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: generators vs forEach
Jeremy Martin wrote: Regardless of whatever solutions may or may not be appropriate, I at a minimum echo Claus' sentiment - it seems like there's a nice opportunity here to improve the modeling of control structures. You're right, but the problem Mark cites is a big one and it stops any general call/cc or coroutine extension from going into JS. I'd just add that call/cc in Scheme is a power tool, and (I'm told) you're supposed to use macros built on it, usually. The macros for delimited continuations address a sweet spot for control abstractions, and Dave Herman did give them careful consideration. Dave alludes to that work here: https://mail.mozilla.org/pipermail/es-discuss/2010-December/012284.html viz, I pretty much abandoned that line of investigation with the conclusion that generators: ..., which I believe refers to http://wiki.ecmascript.org/doku.php?id=strawman:shallow_continuations which is deferred and pretty much defunct due to generators. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Language Negotiation API
On Sun, Jul 14, 2013 at 5:20 AM, Andy Earnshaw andyearns...@gmail.com wrote: I certainly do, at least for Canonicalize-. I've come across one user agent that returns `navigator.language` in non-canonical form which presented a small problem for data I had stored with canonical file names. This was a WebKit based Smart TV platform from 2012, so it was fairly recent, there could be other platforms or frameworks that do the same. FWIW, exposing a new API because another API is broken in a particular implementation is a known anti-pattern. We should fix problems at the source. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: new Symbol(obj)
The builtin could have weak values (i.e. Symbol instances expire when no longer referenced by JS) instead of weak keys, which is not something we can currently express in JS. This would also make it possible to use strings/integers/floats as Symbol keys without leaking those Symbol instances forever. This is not something we can express in JS either. Both of these behaviors would not, as I understand it, be directly observable since keeping an old Symbol instance around (to compare with) would prevent the cached one from being collected. On the other hand, I think if you were to resynthesize the number/string used as a symbol key and make a new symbol, that might allow you to observe whether the symbol had been collected. This doesn't seem like a huge problem to me but I forget the exact reasoning why weak references were unacceptable in the past; maybe it still applies to this. On Mon, Jul 15, 2013 at 9:08 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Jul 15, 2013, at 6:49 AM, Jeremy Martin wrote: In some (most?) cases, but not all. There's already a consensus that the garbage collection semantics of WeakMaps aren't always appropriate [2]. By parameterizing the Symbol constructor, developers can create custom map/set types without the overhead of a Symbol Factory (as previously suggested by Allen). I believe this would be a useful building block for interesting and innovative custom types. [1]: https://en.wikipedia.org/wiki/Injective_function#Definition [2]: http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets An implementation of your proposal is going to have to have to internally use some wort of weak-keyed table, in practice an implementation would probably use the same GC mechanisms that are there to support WeakMap. So, I doubt there would be much performance difference between a built-in and a roll-your-own implementation. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: generators vs forEach
There is no need to CPS transform functions and there is no need for
deferred functions either. It can all be done with today's generators and a
little helper library.
With the C# async/await notation:
- The yield keyword is your await keyword.
- The little * in function* is your async keyword.
With this you can write:
function* asyncEach(array, fn) {
for (var i = 0; i array.length; i++) yield fn(array[i], i);
}
and you can call it as:
function* myFunc(array) {
yield asyncEach(array, function*(elt, i) {
var foo = yield asyncBar(elt);
// more ...
})
}
Note that there is *no* helper API in all these async functions that call
other async functions; The helper API is only needed to interface this with
the classical callback world: at the very bottom of the stack when you call
low level callbacks-based I/O functions, and at the top of the stack when
the event loop runs one of your generator functions.
The trick is that you need a clever run function to do the little
yield/next dance with generator functions that call other generator
functions.
I've implemented this in
https://github.com/bjouhier/galaxy/blob/master/lib/galaxy.js (the run and
invoke functions)
The only thing I don't like about it is the awkward syntax:
- yield precedence does not work well
- yield is prefix, which does not chain well
- and yield is heavy anyway
In short, this is a hack to get going but I'm still waiting for the full
concurrency proposal and its awesome ! syntax.
Bruno
Consider the following:
function* yieldEach(array){
array.forEach(n = {
yield n;
});
}
In order for this to work, not only does `yieldEach` have to be suspended
for the inner yield, but forEach does as well. That means CPS transforming
functions based on whether they call a yielding function.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Language Negotiation API
On Mon, Jul 15, 2013 at 9:37 PM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, Jul 14, 2013 at 5:20 AM, Andy Earnshaw andyearns...@gmail.com wrote: I certainly do, at least for Canonicalize-. I've come across one user agent that returns `navigator.language` in non-canonical form which presented a small problem for data I had stored with canonical file names. This was a WebKit based Smart TV platform from 2012, so it was fairly recent, there could be other platforms or frameworks that do the same. FWIW, exposing a new API because another API is broken in a particular implementation is a known anti-pattern. We should fix problems at the source. Normally, I would agree. However, I was just using my scenario as an example for where exposing the API would have been useful for me. I can also think of a few other reasons: - Language tags can be in extlang form or canonical form. Depending on the source providing the language tag, it's not guaranteed to be the canonical form (extlang form can reinstate extlang subtags that were removed during canonicalisation). - The Internationalization API doesn't cover all aspects of its namesake, like translation, or formatting of postal codes or telephone numbers, as a few examples. Developer libraries could augment Intl with this data, so it would make lives easier if we exposed CanonicalizeLanguageTag to be used by such libraries. - Canonicalisation has at least a couple of optional steps (like normalising case or ordering variant subtags) so exposing a canonicalizing method would give developers a way to achieve consistency with the Internationalisation API. navigator.language isn't part of any stable specification, and even the current HTML 5.1 draft doesn't specify that tags should be returned in canonical form. Do you think it would be a good idea to raise an issue for this? Andy ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Language Negotiation API
On Mon, Jul 15, 2013 at 7:51 PM, Andy Earnshaw andyearns...@gmail.com wrote: navigator.language isn't part of any stable specification, and even the current HTML 5.1 draft doesn't specify that tags should be returned in canonical form. Do you think it would be a good idea to raise an issue for this? Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=22681 -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: generators vs forEach
Bruno, wouldn't yield* work here to delegate the inner yields?
Sent from my Windows Phone
From: Bruno Jouhiermailto:bjouh...@gmail.com
Sent: 7/15/2013 4:12 PM
To: es-discussmailto:es-discuss@mozilla.org
Subject: Re: generators vs forEach
There is no need to CPS transform functions and there is no need for deferred
functions either. It can all be done with today's generators and a little
helper library.
With the C# async/await notation:
* The yield keyword is your await keyword.
* The little * in function* is your async keyword.
With this you can write:
function* asyncEach(array, fn) {
for (var i = 0; i array.length; i++) yield fn(array[i], i);
}
and you can call it as:
function* myFunc(array) {
yield asyncEach(array, function*(elt, i) {
var foo = yield asyncBar(elt);
// more ...
})
}
Note that there is *no* helper API in all these async functions that call other
async functions; The helper API is only needed to interface this with the
classical callback world: at the very bottom of the stack when you call low
level callbacks-based I/O functions, and at the top of the stack when the event
loop runs one of your generator functions.
The trick is that you need a clever run function to do the little yield/next
dance with generator functions that call other generator functions.
I've implemented this in
https://github.com/bjouhier/galaxy/blob/master/lib/galaxy.js (the run and
invoke functions)
The only thing I don't like about it is the awkward syntax:
* yield precedence does not work well
* yield is prefix, which does not chain well
* and yield is heavy anyway
In short, this is a hack to get going but I'm still waiting for the full
concurrency proposal and its awesome ! syntax.
Bruno
Consider the following:
function* yieldEach(array){
array.forEach(n = {
yield n;
});
}
In order for this to work, not only does `yieldEach` have to be suspended for
the inner yield, but forEach does as well. That means CPS transforming
functions based on whether they call a yielding function.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: generators vs forEach
I assume you are referring to something like Q.async/Q.spawn to turn the
generator into an async function using promises?
Sent from my Windows Phone
From: Ron Bucktonmailto:rbuck...@chronicles.org
Sent: 7/15/2013 5:02 PM
To: Bruno Jouhiermailto:bjouh...@gmail.com;
es-discussmailto:es-discuss@mozilla.org
Subject: RE: generators vs forEach
Bruno, wouldn't yield* work here to delegate the inner yields?
Sent from my Windows Phone
From: Bruno Jouhiermailto:bjouh...@gmail.com
Sent: 7/15/2013 4:12 PM
To: es-discussmailto:es-discuss@mozilla.org
Subject: Re: generators vs forEach
There is no need to CPS transform functions and there is no need for deferred
functions either. It can all be done with today's generators and a little
helper library.
With the C# async/await notation:
* The yield keyword is your await keyword.
* The little * in function* is your async keyword.
With this you can write:
function* asyncEach(array, fn) {
for (var i = 0; i array.length; i++) yield fn(array[i], i);
}
and you can call it as:
function* myFunc(array) {
yield asyncEach(array, function*(elt, i) {
var foo = yield asyncBar(elt);
// more ...
})
}
Note that there is *no* helper API in all these async functions that call other
async functions; The helper API is only needed to interface this with the
classical callback world: at the very bottom of the stack when you call low
level callbacks-based I/O functions, and at the top of the stack when the event
loop runs one of your generator functions.
The trick is that you need a clever run function to do the little yield/next
dance with generator functions that call other generator functions.
I've implemented this in
https://github.com/bjouhier/galaxy/blob/master/lib/galaxy.js (the run and
invoke functions)
The only thing I don't like about it is the awkward syntax:
* yield precedence does not work well
* yield is prefix, which does not chain well
* and yield is heavy anyway
In short, this is a hack to get going but I'm still waiting for the full
concurrency proposal and its awesome ! syntax.
Bruno
Consider the following:
function* yieldEach(array){
array.forEach(n = {
yield n;
});
}
In order for this to work, not only does `yieldEach` have to be suspended for
the inner yield, but forEach does as well. That means CPS transforming
functions based on whether they call a yielding function.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
New ES6 draft now available, Rev 16
A new ES6 draft is now available at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts This is the Rev 16, July 15, 2013 draft. Major changes include: • Restored MOP internal methods [[IsExtensible]]/[[PreventExtensions]] in place of [[HasIntegery]]/[[SetIntegrity]] • Added [[Invoke]] internal method to the MOP. Revised evaluation semantics of function calls (including super calls) to use invoke) • Provided full complement of internal methods for Integer Index exotic objects (Typed Array views) • Reverted Symbols to being a kind of Exotic object rather than a new primitive type • Added computed symbol property definitions eg, [ ] to object literals and class definitions. • Updated BNF to support refutable patterns • Made trailing ; optional for do-while statements • Simplified this binding semantics of Generator functions. • Updated Array.from algorithm to include mapping behavior • Generalize Array concat to deal with “spreading” array subclasses that may not be exotic arrays • Factor common TypedArray method into %TypedArray% abstract “class” as per plan of record. • Added of and from factory methods for Typed Arrays • Added applicable Array methods to %TypedArrayPrototype% (in some cases, thus stub sections) • Made Typed Arrays Iterables with @@iterator, keys, values, entries methods • Complete rewrite of DaveView specification. • Map and WeakMap constructors try using entries methods before @@iterator method to initialize new instances • Added WeakSet • Added Reflect.invoke • Change from ES5: Object.freeze/seal/preventExensions. on primitives is a now a no-op. isFrozen/isSealed returns true. IsExtensible returns false. •Bugs: 1577, 1576, 1573, 1570, 1568-1566, 1564-1562, 1558, 1554, 1551-1549, 1546-1534, 1524, 1520-1476, 1434, 1417, 1405, 1400, 1398, 1396, 1391, 1375, 1365, 1354, 1317, 1315, 1295, 1290, 1283, 1276, 1269, 1265, 1213, 1201, 1196, 1194, 1175, 1146, 1085, 1057, 974, 965, 964, 962, 961, 955, 951, 936, 933, 930, 920, 903, 896, 892, 882, 793, 782, 781, 746, 743, 735, 734, 731-727, 715, 713, 711, 682, 677-675, 377, 313, 158 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New ES6 draft now available, Rev 16
On 7/15/2013 5:52 PM, Allen Wirfs-Brock wrote: A new ES6 draft is now available at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts This is the Rev 16, July 15, 2013 draft. The bookmarks/index in the PDF versions has a lot of extra cruft in it (1, 1, 1, 1, 1.1, 1.1, 1.1, etc). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New ES6 draft now available, Rev 16
I know and it's noted on the wiki. This draft changed how section headings are done and something seems to be confusing the PDF bookmark generation. You just have to ignore them for now. Brandon Benvie bben...@mozilla.com wrote: On 7/15/2013 5:52 PM, Allen Wirfs-Brock wrote: A new ES6 draft is now available at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts This is the Rev 16, July 15, 2013 draft. The bookmarks/index in the PDF versions has a lot of extra cruft in it (1, 1, 1, 1, 1.1, 1.1, 1.1, etc). ___ 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: How primitive are Symbols? Bignums? etc
The (x === Object(x)) test evaluates to true for value objects in this proposal, though. This may break code looking for primitives but we need to see what such code expects. Is it filtering out the legacy typeof-result primitives (plus null), trying to find values for which typeof currently returns object or function? If so, I don't see a problem: int64, bignum, etc. are not legacy primitives. Is this test looking for objects that are their own wrappers? Again all is well, unless mutable wrapper is assumed -- but that's not safe in the ES5 era to assume, anyway. The most frequent use case I’ve encountered: does the value have a prototype (i.e., will Object.getPrototypeOf() work)? I’m assuming that value objects will have a prototype, accessible via Object.getPrototypeOf (?) Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How primitive are Symbols? Bignums? etc
Axel Rauschmayer wrote: The (x === Object(x)) test evaluates to true for value objects in this proposal, though. This may break code looking for primitives but we need to see what such code expects. Is it filtering out the legacy typeof-result primitives (plus null), trying to find values for which typeof currently returns object or function? If so, I don't see a problem: int64, bignum, etc. are not legacy primitives. Is this test looking for objects that are their own wrappers? Again all is well, unless mutable wrapper is assumed -- but that's not safe in the ES5 era to assume, anyway. The most frequent use case I’ve encountered: does the value have a prototype (i.e., will Object.getPrototypeOf() work)? I’m assuming that value objects will have a prototype, accessible via Object.getPrototypeOf (?) Yes, they are after all value objects :-P. js Object.getPrototypeOf(0UL) 0UL /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
