yield syntax (diverging from: How would shallow generators compose with lambda?)
brendan at mozilla.com
Mon May 18 12:26:51 PDT 2009
On May 18, 2009, at 12:15 PM, Neil Mix wrote:
> Ah, but delete and typeof are different in that they both *require*
> an argument (terminology be damned, hopefully you understand what I
> mean by that.) And return is different because it can't be used in
> an expression. See my previous let x = yield-5; example -- let x =
> typeof-5; is unambiguous.
> I'm tempted to argue that yield should require an argument, and then
> you could give it precedence equivalent to delete and typeof. But
> that would make a statement like
> yield x - 1;
> utterly confusing.
Yes; I pointed that out earlier in this thread:
"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."
But this objection applies to yield expressions in larger expressions
> Set aside for a moment the argument of *which* form of parenthesis
> for a moment, and assume (yield E) wins for now. Could we redefine
> yield so that it has two forms, a statement form and an expression
> form? The statement form would be
> yield E;
> where E is optional. And the expression form would be
> yield E
> where E is required, and yield has precedence equivalent to delete
> and typeof. Is that possible? Doing so would render any argument
> about parenthesis moot, since they'd rarely be required, right?
Not clear. Using yield in a larger expression may nevertheless want to
yield an expression with precedence lower than unary (delete, !, etc.)
precedence. ES3 grammar:
Since yield has some some similarity to return I'm still in favor of
what Python did: low precedence, mandatory parenthesization of the
whole yield expression in any non-statement context. JS1.7 tried to
relax this, but it's not worth it as your experience says.
More information about the es-discuss