'function *' is not mandatory
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
> 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
> 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
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