yield syntax (diverging from: How would shallow generators compose with lambda?)
brendan at mozilla.com
Sun May 17 17:01:47 PDT 2009
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 (22.214.171.124.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
>> check is whether the value of the eval variable is the original
>> 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
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
But when there's no larger expression, why require gratuitous
More information about the es-discuss