On Mon, Sep 2, 2013 at 12:09 AM, Brendan Eich <[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>`.
> 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
families.
>
>> ) 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
have.
> 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
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
