6 ms·

The asterix after the function keyword smells like a syntax hack. Firefox did it right, https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScrip

by mhitza 13y ago

The asterix after the function keyword smells like a syntax hack. Firefox did it right, https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/1.7 https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_...

masklinn 13y ago
Depends what you mean by "syntax hack". Its point is to create a syntactic scope where `yield` can not currently exist and can be reserved. Since yield is a valid name in javascript today there might be code in the wild going function foo() { yield = some_computation(); return yield; } this code would be broken by enabling generators. Same with yield* foo() (which would be interpreted as multiplying the variable `yield` by the result of `foo()` in ES5). It also creates a nice parallelism between function* and yield, as a side-effect. See http://esdiscuss.org/topic/proposal-to-simplify-generators-impact#content-1 http://esdiscuss.org/topic/proposal-to-simplify-generators-i..., there should be more extensive previous discussions in es-discuss and TC39 notes but it's a pain in the ass to look it up. edit: https://mail.mozilla.org/pipermail/es-discuss/ https://mail.mozilla.org/pipermail/es-discuss/ also points to the use case of 0-item generators — mostly in relation to delegating from yield — with function* () {} in Python (and JS/1.7) you'd need the unwieldy function() { if (false) yield } and notes that having a star in the header function makes it easier on the reader.
- deleted 13y ago
  [deleted]
- 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/
- apaprocki 13y ago
  > ... there might be code in the wild going ... There definitely is. We have millions of lines of JS and many applications that deal with yield of a security. This yield: http://www.investopedia.com/terms/y/yield.asp http://www.investopedia.com/terms/y/yield.asp
  - deleted 13y ago
    [deleted]
  - masklinn 13y ago
    Excellent point.
- michielvoo 13y ago
  imho C# has a nicer syntax: yield return <expression>; yield break; http://msdn.microsoft.com/en-us/library/vstudio/9k7k7cf0.aspx http://msdn.microsoft.com/en-us/library/vstudio/9k7k7cf0.asp...
  - masklinn 13y ago
    how is `yield return` and `yield break` nicer than `yield` and `return` exactly?
    - michielvoo 13y ago
      Nicer than "function *" I meant.
apaprocki 13y ago
> Firefox did it right That is the "old" yield. It has been transformed into the new ES6 yield (w/ function*) in the current Firefox nightly.

by mhitza 13y ago

masklinn 13y ago

Depends what you mean by "syntax hack". Its point is to create a syntactic scope where `yield` can not currently exist and can be reserved. Since yield is a valid name in javascript today there might be code in the wild going function foo() { yield = some_computation(); return yield; } this code would be broken by enabling generators. Same with yield* foo() (which would be interpreted as multiplying the variable `yield` by the result of `foo()` in ES5). It also creates a nice parallelism between function* and yield, as a side-effect. See http://esdiscuss.org/topic/proposal-to-simplify-generators-impact#content-1 http://esdiscuss.org/topic/proposal-to-simplify-generators-i..., there should be more extensive previous discussions in es-discuss and TC39 notes but it's a pain in the ass to look it up. edit: https://mail.mozilla.org/pipermail/es-discuss/ https://mail.mozilla.org/pipermail/es-discuss/ also points to the use case of 0-item generators — mostly in relation to delegating from yield — with function* () {} in Python (and JS/1.7) you'd need the unwieldy function() { if (false) yield } and notes that having a star in the header function makes it easier on the reader.

deleted 13y ago
[deleted]
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/
apaprocki 13y ago
> ... there might be code in the wild going ... There definitely is. We have millions of lines of JS and many applications that deal with yield of a security. This yield: http://www.investopedia.com/terms/y/yield.asp http://www.investopedia.com/terms/y/yield.asp
- deleted 13y ago
  [deleted]
- masklinn 13y ago
  Excellent point.
michielvoo 13y ago
imho C# has a nicer syntax: yield return <expression>; yield break; http://msdn.microsoft.com/en-us/library/vstudio/9k7k7cf0.aspx http://msdn.microsoft.com/en-us/library/vstudio/9k7k7cf0.asp...
- masklinn 13y ago
  how is `yield return` and `yield break` nicer than `yield` and `return` exactly?
  - michielvoo 13y ago
    Nicer than "function *" I meant.

apaprocki 13y ago

> Firefox did it right That is the "old" yield. It has been transformed into the new ES6 yield (w/ function*) in the current Firefox nightly.