'function *' is not mandatory

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Sun Sep 1 22:03:03 PDT 2013

On Mon, Sep 2, 2013 at 12:09 AM, Brendan Eich <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>`.

>  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? I suppose it looking confusing to me
doesn't qualify as a strong justification to revert a decision like this.

I'm obviously not going to convince you that the star is a bad idea?

>  Why not tilde? Or plus? Why take something that already has a completely
>> different meaning in other languages?
> Rust uses tilde for unique references / linear types. Someone has to pay.

Exclamation mark? Percentage symbol? There's a dozen other punctuation
options, maybe one of them would make it look less like something
completely different in one of the most popular programming language

>>     ) instead of something clearer, e.g. `generator myGenerator ()
>>     {}`? I see the obvious ASI hazard, but this can be mitigated by
>>     not allowing unnamed generators, e.g. `{ myGenerator: generator _
>>     () {} } `,
>>     This doesn't work in general, it is backward-incompatible. If
>>     someone bound or assigned to generator in-scope, your proposed
>>     change could break compatibility -- or else require parsing to
>>     depend on name binding.
>>     foo = generator
>>     bar()
>>     {}
>>     Remember, if there wasn't an error, ASI doesn't apply. Trying to
>>     "patch" this bad theory with a [no LineTerminator here]
>>     restriction to the right of 'generator' does not work in the
>>     grammar without reserving 'generator' -- we can't put that
>>     restriction to the right of every Identifier on the right of every
>>     expression production.
>> Can you elaborate on this, please, I'm confused? Why can't we restrict
>> the syntax?
> You have to propose exactly *how* you want to "restrict the syntax".
> As I just wrote, we cannot restrict all productions with Identifier in
> their right-hand sides to forbid line terminators after. Any restriction
> would be word-sensitive and require 'generator' to be reserved. Then the
> problem becomes backward incompatibility of the kind I showed. To avoid
> breaking such code (and other cases not yet thought of) requires a
> grammatical restriction of some sort. What sort?

So `generator [no LineTerminator here] BindingIdentifier [no LineTerminator
here] ( FormalParameters ) { FunctionBody }` couldn't be done? The parser
can't be word-sensitive without flagging that word as a keyword? Sounds
like an arbitrary limitation that should be fixed.

Even `generator function BindingIdentifieropt ( FormalParameters ) {
FunctionBody }` would be better at describing what it does than what we

>  Unrestricted syntax is why we are having this discussion in the first
>> place. What's the negative effect of reserving 'generator'? In my opinion
>> the parser saying "ohmigod"
> Please stop informal rambling and specify exactly what you mean.
> /be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130902/2293deeb/attachment.html>

More information about the es-discuss mailing list