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

[Brendan Eich]

On May 17, 2009, at 1:11 PM, Brendan Eich wrote:

> On May 17, 2009, at 12:43 PM, Mark S. Miller wrote:
>
>> On Sun, May 17, 2009 at 11:00 AM, Brendan Eich  
>> <brendan at mozilla.com> wrote:
>>> Analogous to direct vs. indirect eval in ES5 (15.1.2.1.1), there  
>>> is no
>>> purely syntactic specification for what Neil proposes. A runtime  
>>> check is
>>> required. So I don't see why you are focusing only on syntax here.
>>
>> I don't follow. What runtime check? For the eval operator, the  
>> runtime
>> check is whether the value of the eval variable is the original  
>> global
>> eval function. It makes no sense to have a corresponding global yield
>> function value.
>
> If we reserve yield then you're right.

It's goofy to have

return w;
delete x.y;
typeof z;
yield a; => SyntaxError! must use yield(a)

The mandatory parentheses could be avoided by breaking from Python's  
precedent and making yield a canonical unary (that is,  
high-)precedence operator like delete, !, etc. But then almost any  
algebraic or logical expression computing the value to yield would  
need parentheses, and people would make mistakes such as yield a + b  
where they meant yield(a + b) -- as in Python -- but got yield(a) + b.

This is one reason, if I recall some PEP text correctly, why Python  
requires parentheses around all yield expressions except those on the  
right of assignment operators in assignment statements, and in yield  
statements. It seems best to require explicit parentheses when yield  
is part of a larger expression, no matter the precedence of its  
optional argument/operand.

But when there's no larger expression, why require gratuitous  
parentheses?

/be