- 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 <[email protected]>:
> 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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
