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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150212/f1eec448/attachment-0001.html>

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?

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?

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?