'function *' is not mandatory

Brendan Eich brendan at mozilla.com
Sun Sep 1 22:47:52 PDT 2013

> Jussi Kalliokoski <mailto:jussi.kalliokoski at gmail.com>
> September 1, 2013 10:03 PM
> On Mon, Sep 2, 2013 at 12:09 AM, Brendan Eich <brendan at mozilla.com 
> <mailto:brendan at mozilla.com>> wrote:
>                 but why `function *` (which looks like a pointer to a
>         function
>                 more than a generator
>             This is JS, please take off your C/C++ hat :-P.
>         Sure, but let's not ignore that this syntax already has a
>         special meaning in the language family JS syntax is heavily
>         based on.
>     What syntax? 'function' is not a reserved word in C or C++. It is
>     in AWK, which is arguably in the C family. Sorry, but JS syntax is
>     not bound to evolve only in ways that are disjoint from
>     keyword-free reinterpretation as C or C++.
> No, 'function' is not a reserved word in C/++, who said it was? I'm 
> saying `function *myGenerator` looks a lot like `<type> *<identifier>`.

We're going in circles: I'm saying (I said) take off the C/C++ hat.

JS's future syntax is *not* under a 
do-not-mimic-C/C++-ignoring-keywords-and-semantics constraint.

>         Like I asked, why does it have to be the star?
>     Yes, it has to be star. This is not the hill you want to die on,
>     metaphorically speaking. TC39 reached consensus based on a
>     championed proposal. Re-opening this minor design decision needs
>     strong justification. Trying to avoid looking like C or C++ at a
>     glance is not strong justification.
> I'm aware of the decision, the rationale behind it is what I'm looking 
> for. Or was star picked just because?

No, think about yield* for delegation. We want consonance, reuse of 
"generator sigil".

Your comments on the grammar show continued informality and lack of 
familiarity with parsing theory in general, and the ECMA-262 grammar 
formalisms in particular. We don't want to split 'generator' out from 
Identifier, and special-case its syntax in PrimaryExpressions (which 
must be covered by a cover-grammar that also covers destructuring). We 
don't have a convenient formalism for such special-casing.

What's more, special-casing 'generator' is more than a spec and 
implementation front-end complexity tax. It makes a longer and more 
complex path dependency for any future syntax extension nearby (e.g., 
Mark's function! for async function syntax, proposed for ES7 -- 
controversial, and perhaps ^ is better than !, but in any case this is 
easy to do given function*, not so easy to do given generator|function 
syntax). Special cases are a smell.

Finally, no way will we lumber everyone writing generators with a 
double-keyword 'generator function'. That's too much on several 
dimensions. TC39's consensus for function* is worth keeping, over 
against your inability to take off the C/C++ hat. Of this I am certain, 
even if the * is somewhat arbitrary (but see above about yield*).

So at this point, to be frank and with the best intentions, I think 
you're being a sore loser ;-). It's no fun to lose, I've had to learn to 
cope over the years big-time (JS in its rushed glory; ES4; etc.). This 
'*' is very small potatoes, as the saying goes.


More information about the es-discuss mailing list