yield syntax (diverging from: How would shallow generators compose with lambda?)

[Brendan Eich]

On May 14, 2009, at 5:13 PM, David-Sarah Hopwood wrote:

> 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.

Were you responding to Neil instead of me? I'm not advocating Neil's  
proposal, but it seems to me he's arguing for it to avoid the  
mandatory parentheses around the entire yield expression in almost any  
surrounding expression in which it could be embedded. He is right that  
requiring parentheses around yield's operand avoids mandatory parens  
around yield expressions in list contexts.

Simpler to implement is not the issue, but it's a wash as you say.


> 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.

Yes, but it's not that complicated. SpiderMonkey and Rhino do it. Code  
size burden is in the noise.


>> 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.

Ok.

I was replying to Neil, not to you (hadn't seen any message from you  
on this sub-thread).

/be

>
>
> -- 
> David-Sarah Hopwood ⚥
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss