Comment by masklinn | Hacker News Reader

Comment by masklinn | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com