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...@gmail.com <mailto:polkovnikov...@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....@outlook.com
<mailto:francois.remy....@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@mozilla.org <mailto: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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
