d at domenic.me (2015-03-06T00:37:21.522Z)
Yep. This was already discussed in the topic I mentioned before. Just to remember, the real problem with tee() is that the generators are not actually independent as you can not .send() different information to each one to make them diverge. So producing a real clone of the generator is not possible from "above the standard". Hope it helps.
Yep. This was already discussed in the topic I mentioned before. Just to remember, the real problem with tee() is that the generators are not actually independent as you can not .send() different information to each one to make them diverge. So producing a real clone of the generator is not possible from "above the standard". Hope it helps. El 22/02/2015 20:19, "Brendan Eich" <brendan at mozilla.org> escribió: > As the comments from Tab Atkins and John Lenz there suggest, this is best > done above the level of the standard, for now. If we need to roll up > itertools including tee in ES7 (I am pretty sure we do), the best way to > get there is via github -- not by prematurely standardizing APIs or > over-extending language kernel semantics in TC39. > > /be > > Salvador de la Puente González wrote: > >> Hey Philip, >> >> you can see https://esdiscuss.org/topic/proposal-generator-clone-and- >> generator-goto for more about this topic. >> >> On Wed, Feb 18, 2015 at 2:02 PM, Philip Polkovnikov < >> polkovnikov.ph at gmail.com <mailto:polkovnikov.ph at gmail.com>> wrote: >> >> - 1. Where is the function `run`? >> >> The function `run` is pretty classic variation on the code you >> would see in `Q` or `bluebird`. >> >> function run(gen) { >> return function (/* args */) { >> var args = Array.prototype.slice.call(arguments); >> var iter = gen.apply(args); >> (function step(arr) { >> arr.forEach(function (item) { >> iter.copy().next(item); >> }); >> })(iter.next()); >> }; >> } >> >> Probably, it would be nice to work out `return` there, so that >> this could be a full-fledged nondeterminism monad, but everything >> should be already clear. >> >> - 2. I am against copying a generator instance. It's just like >> cloning a context, with many difficulties and ambiguity. Shall we >> deep-clone or not? How to efficiently implement such a method? I >> don't see useful cases in which we need to clone a generator instance. >> >> Regarding the availability of `.copy()` you can read in the >> description of one Python package I've just found: >> >> http://www.fiber-space.de/generator_tools/doc/generator_tools.html >> >> - Given how close ES6 is to ship, I think it's too late to make >> such changes to the spec, we will have to live with it. Use >> Traceur to generate state machines from your "yield functions" and >> use that as a basis in your code. >> >> The `copy` is worth the problems of frame copying. Anyway, I >> understand that ES6 won't have `copy` as standard is just to be >> released, but it should be added to JS once. >> >> 2015-02-13 21:35 GMT+03:00 François REMY >> <francois.remy.dev at outlook.com >> <mailto:francois.remy.dev at outlook.com>>: >> >> For the record, I proposed this feature before, and it wasn't >> seen as a good idea, for some reason: >> https://esdiscuss.org/topic/function-is-not-mandatory#content-47 >> >> Given how close ES6 is to ship, I think it's too late to make >> such changes to the spec, we will have to live with it. Use >> Traceur to generate state machines from your "yield functions" >> and use that as a basis in your code. >> >> Best regards, >> François >> >> _______________________________ >> >> As pretty everyone already seen, generators are usually used >> in composition with promises to yield (pun intended) a plain >> simple linear code. This solution looks very much like monads >> from Haskell, yet in a better syntax: every a <- b in Haskell >> is a = yield b in JS, and that aids to get rid of several >> useless lines of code. >> >> Actually, one could easily implement other monads over >> Haskell, changing the structure of the data passed to `yield`. >> Generators + promises are almost a Cont monad (continuations). >> But here's an issue. >> >> Let's take a look at the List monad (nondeterminism), >> specifically how we would use one in JS: >> >> function* doesntMatter() { >> var a = yield [1, 2, 3]; >> var b = yield [1, 2, 3]; >> return a + b; >> } >> >> Now, when we run(doesntMatter)(), we should get [2, 3, 4, 3, >> 4, 5, 4, 5, 6]. But there's a problem with implementation: we >> would like to run the rest of the computation for every item >> in an array passed to `yield`, but we can't! There's no way >> one could copy the current state of an iterator. >> >> The same happens to our original generator + promise usage. We >> could use the same syntax to work with events (i.e. repetitive >> callback calls), not just series of nested callbacks, but we >> don't have that vital iter.copy() method. >> >> Obviously, mentioning Haskell in this message was overkill, >> and that could be a reason for someone to diasgree that we >> really need such feature. But, as I previously described, it's >> quite a natural thing that is missing, and it doesn't have too >> much in common with Haskell. >> >> What is the right way to put this thing into >> discussion/standardization process? What do you think about it? >> >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org> >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150223/dffe1af3/attachment.html>