Jussi Kalliokoski <mailto:[email protected]>
September 1, 2013 10:03 PM
On Mon, Sep 2, 2013 at 12:09 AM, Brendan Eich <[email protected]
<mailto:[email protected]>> 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.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
