'function *' is not mandatory
jussi.kalliokoski at gmail.com
Mon Sep 2 00:05:37 PDT 2013
On Mon, Sep 2, 2013 at 8:47 AM, Brendan Eich <brendan at mozilla.com> wrote:
> Jussi Kalliokoski <mailto:jussi.kalliokoski@**gmail.com<jussi.kalliokoski at gmail.com>
>> September 1, 2013 10:03 PM
> 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
Of course not. That doesn't mean we should ignore what other common
languages do with the same syntax. And at best, with my C/++ skills, it's
more like a kippah than a real hat. ^^
> 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".
Googling generator sigil yields online magic symbol generators... Not what
I was looking for, I think. :) Is the star after yield any less arbitrary?
> 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.
They probably do since I am not familiar with parsing theory in general,
but I probably represent a large portion of the community with that
disability (which I hope to repair at some point). I wouldn't ask the
questions if I knew the answers, now would I. To me this seems just like
arbitrary limitations where it's somehow impossible to add an if statement
in the parser.
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.
All right, so it would be a much larger effort to specify it?
> 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.
I agree with special cases being a smell, but hacks are a smell too (hacks
lead to the need for special cases), and `function *` is definitely a hack
around the limitations we have (arbitrary or not). So two smelly things,
the difference is that only one of them conveys the intended meaning at
first glance, but only one has been agreed upon
> 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*).
I also realized a bit after sending the message that it wouldn't even avoid
the [no LineTerminator here] problem, sorry. >,<
> 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.
Don't worry, I know quite well how to lose, in fact I consider losing as
one of the things I'm best at. But when I'm proven wrong, I want to
understand why I was wrong. Where you are now seeing a sore loss, I see a
triumph in learning new things. ;)
However I see this is a sunk cost and beating a dead horse, so I rest my
case (that's not to say I wouldn't appreciate my questions getting
answered). Sorry for making you repeat yourself.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss