Brendan Eich wrote:
> On May 14, 2009, at 1:14 PM, Neil Mix wrote:
>
>> I have this idea that it would be better for yield expressions to look
>> like function calls: 'yield' '(' expression? ')'. (Note that this is
>> only a syntactical suggestion; clearly an implementation wouldn't
>> actually treat it like a function.) That would eliminate the
>> precedence issues Brendan cites while also making the syntax backward
>> compatible with earlier ES parsers. Is there any technical reason why
>> that wouldn't be possible?
>
> The syntax could work but we need to reserve yield contextually.
> It can't be a user-defined function name and a built-in function. The
> compiler must unambiguously know that yield (the built-in) is being
> called in order to make the enclosing function a generator.
>
> This is reason enough in my view to keep yield a prefix operator and
> reserve it.
But that doesn't help: the argument to yield is an arbitrary expression,
so 'yield (foo)' could be either a function call or a yield-expression.
That means that this approach can at best be no simpler to implement or
specify than the function call syntax.
With the function call syntax, it would be sufficient to keep the
existing ES5 grammar for function calls, and then check after parsing
whether a MemberExpression or CallExpression followed by Arguments is
the string "yield". With the operator syntax, it's more complicated
than that because there are more syntactic contexts to consider.
> Another reason is your duck/cow point, which I think is a separate point
> from compiler analyzability. Really, no one writes yield(...) in Python,
> and extra parens hurt (I know RSI sufferers who benefit from lack of
> shifting in Python and Ruby).
Yes, those are separate points that I am not arguing against here.
--
David-Sarah Hopwood ⚥
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
