3 ms·

Why would yield as an lvalue or var conflict with yield as a statement? Yes it would be unavoidable if a variable named yield was used as a statement, but that'

by ynniv 13y ago

Why would yield as an lvalue or var conflict with yield as a statement? Yes it would be unavoidable if a variable named yield was used as a statement, but that's a pretty strange thing to do. Reserved words are unnecessary. As to convenient empty generators, they don't need to be enabled by syntax. You could define a function empty_gen() that is even fewer characters than function* () {}.

masklinn 13y ago
> Why would yield as an lvalue or var conflict with yield as a statement? yield is not just a statement, it's also an expression. `yield` as an lvalue is the one case where they wouldn't conflict. The issue is the return, or a preexisting `yield` function. > Yes it would be unavoidable if a variable named yield was used as a statement, but that's a pretty strange thing to do. `yield` as a variable is not a strange thing to do, and `yield(something)` would also conflict with yielding a value. > Reserved words are unnecessary. I've got no idea why you put that here. The whole point is that yield can't be a global reserved word, yet it needs to be a special syntactic form. > As to convenient empty generators, they don't need to be enabled by syntax. You could define a function empty_gen() So now ES6 needs to define a new function in the global namespace and hope nobody happens to have an `empty_gen` global already?
- ynniv 13y ago
  yield is not just a statement, it's also an expression Perhaps you could give an example of yield as an expression? "x = x + yield" doesn't make a lot of sense to me. > Reserved words are unnecessary. I've got no idea why you put that here The meaning of a symbol can often be inferred from its context - it doesn't need to be a reserved word. So now ES6 needs to define a new function in the global namespace No, if the user cares to save the extra characters, they can define a convenience function. `yield(something)` would also conflict with yielding a value. Yes, it would not be allowable to have an open paren after yield. Something like a syntax colon ("yield:(x + 1)") or a unary operator ("yield +(x + 1)") would be necessary.
  - masklinn 13y ago
    > Perhaps you could give an example of yield as an expression? "x = x + yield" doesn't make a lot of sense to me. And yet it's perfectly valid. ES6 generators are (shallow) coroutines (or "extended generators" in Python-land[0]). From the outside, they provide a `send()` method as the converse to `next()`, and that method is used to inject a value back in the generator, via `yield` as an expression. And yes you can use the same yield to send a value out and retrieve one in the same "yield step". That is how e.g. taskjs[1] works: spawn(function*() { var data = yield $.ajax(url); $('#result').html(data); var status = $('#status').html('Download complete.'); yield status.fadeIn().promise(); yield sleep(2000); status.fadeOut(); }); the first line sends a promise to the scheduler and suspends the generator, the scheduler then resumes the generator with send() to inject the resolution of the promise back in. > The meaning of a symbol can often be inferred from its context - it doesn't need to be a reserved word. Not without function * . the purpose of function * is precisely to provide the context for `yield` being not-a-name. > Yes, it would not be allowable to have an open paren after yield. You do realize how utterly insane that reads right? You propose crippling `yield` and making it significantly less convenient and sensible to get rid function * (and the colon does not work, it conflicts with labels) [0] http://www.python.org/dev/peps/pep-0342/ http://www.python.org/dev/peps/pep-0342/ [1] http://taskjs.org/ http://taskjs.org/
    - ynniv 13y ago
      ES6 generators are (shallow) coroutines This is the first I've heard ES6 generators being coroutines. Is this documented somewhere other than the PEP?
      - masklinn 13y ago
        I'm not sure what you're looking for exactly. The generators proposal defines the `send` method[0] (as well as `throw`) and its semantics. They're not "full" coroutines as they can't yield to an arbitrary coroutine (unless a trampoline is used), only to their parent/caller. [0] http://wiki.ecmascript.org/doku.php?id=harmony:generators#methodnext http://wiki.ecmascript.org/doku.php?id=harmony:generators#me...

by ynniv 13y ago

masklinn 13y ago

> Why would yield as an lvalue or var conflict with yield as a statement? yield is not just a statement, it's also an expression. `yield` as an lvalue is the one case where they wouldn't conflict. The issue is the return, or a preexisting `yield` function. > Yes it would be unavoidable if a variable named yield was used as a statement, but that's a pretty strange thing to do. `yield` as a variable is not a strange thing to do, and `yield(something)` would also conflict with yielding a value. > Reserved words are unnecessary. I've got no idea why you put that here. The whole point is that yield can't be a global reserved word, yet it needs to be a special syntactic form. > As to convenient empty generators, they don't need to be enabled by syntax. You could define a function empty_gen() So now ES6 needs to define a new function in the global namespace and hope nobody happens to have an `empty_gen` global already?

ynniv 13y ago
yield is not just a statement, it's also an expression Perhaps you could give an example of yield as an expression? "x = x + yield" doesn't make a lot of sense to me. > Reserved words are unnecessary. I've got no idea why you put that here The meaning of a symbol can often be inferred from its context - it doesn't need to be a reserved word. So now ES6 needs to define a new function in the global namespace No, if the user cares to save the extra characters, they can define a convenience function. `yield(something)` would also conflict with yielding a value. Yes, it would not be allowable to have an open paren after yield. Something like a syntax colon ("yield:(x + 1)") or a unary operator ("yield +(x + 1)") would be necessary.
- masklinn 13y ago
  > Perhaps you could give an example of yield as an expression? "x = x + yield" doesn't make a lot of sense to me. And yet it's perfectly valid. ES6 generators are (shallow) coroutines (or "extended generators" in Python-land[0]). From the outside, they provide a `send()` method as the converse to `next()`, and that method is used to inject a value back in the generator, via `yield` as an expression. And yes you can use the same yield to send a value out and retrieve one in the same "yield step". That is how e.g. taskjs[1] works: spawn(function*() { var data = yield $.ajax(url); $('#result').html(data); var status = $('#status').html('Download complete.'); yield status.fadeIn().promise(); yield sleep(2000); status.fadeOut(); }); the first line sends a promise to the scheduler and suspends the generator, the scheduler then resumes the generator with send() to inject the resolution of the promise back in. > The meaning of a symbol can often be inferred from its context - it doesn't need to be a reserved word. Not without function * . the purpose of function * is precisely to provide the context for `yield` being not-a-name. > Yes, it would not be allowable to have an open paren after yield. You do realize how utterly insane that reads right? You propose crippling `yield` and making it significantly less convenient and sensible to get rid function * (and the colon does not work, it conflicts with labels) [0] http://www.python.org/dev/peps/pep-0342/ http://www.python.org/dev/peps/pep-0342/ [1] http://taskjs.org/ http://taskjs.org/
  - ynniv 13y ago
    ES6 generators are (shallow) coroutines This is the first I've heard ES6 generators being coroutines. Is this documented somewhere other than the PEP?
    - masklinn 13y ago
      I'm not sure what you're looking for exactly. The generators proposal defines the `send` method[0] (as well as `throw`) and its semantics. They're not "full" coroutines as they can't yield to an arbitrary coroutine (unless a trampoline is used), only to their parent/caller. [0] http://wiki.ecmascript.org/doku.php?id=harmony:generators#methodnext http://wiki.ecmascript.org/doku.php?id=harmony:generators#me...