What does `return function *(){…}` mean in JavaScript? | Hacker News Reader

What does `return function *(){…}` mean in JavaScript?

stackoverflow.com

44 pointsafshinmeh26 comments

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_...

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-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/ 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.

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* () {}.

> 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?

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.

> 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/

[1] http://taskjs.org/

ES6 generators are (shallow) coroutines

This is the first I've heard ES6 generators being coroutines. Is this documented somewhere other than the PEP?

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#me...

> ... 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

Excellent point.

imho C# has a nicer syntax:

  yield return <expression>;
  yield break;

http://msdn.microsoft.com/en-us/library/vstudio/9k7k7cf0.asp...

how is `yield return` and `yield break` nicer than `yield` and `return` exactly?

Nicer than "function *" I meant.

> 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.

But jump to this http://wingolog.org/archives/2013/05/08/generators-in-v8 which explains it properly - and tells you why you would want to do it.

agreed

Does it need to be used with promises?

No. Promises work nicely with generators, but you can use generator functions freely.

Is there any promise-less guide, that helps to grasp the concept of function* and yield in JS?

Not an article, but this is a good library that uses generator functions without promises:

https://github.com/visionmedia/co

Any generator guide for Python will work, the syntax is slightly different (no function/def, the generator is "created" by the presence of a `yield` keyword in the body, and `yield*` is called `yield from`)

The easiest thing to do is probably playing around with it :)

Am I missing something, or does Stack Overflow really have this marked as a duplicate without actually linking to the earlier question? That's not very helpful.

Not sure if it was there when you looked, but I see a link[1] to the relevant question in a grey box at the top of the question. I find the placement to be awkward though, I expected the link to be within the same box as the "marked as duplicate" text.

[1] http://stackoverflow.com/questions/9620586/function-in-javas...

It doesn't stand out very much in this question because it has a big block of code which has the same styling as the alert box. When your interface design has so few colors, this kind of stuff happens.

That's inserted automatically when questions are closed as duplicate.

Reply on news.ycombinator.com