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

Neil Mix nmix at pandora.com
Sun May 17 18:39:10 PDT 2009


On May 17, 2009, at 7:01 PM, Brendan Eich wrote:
> 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.

I'm going to make the argument that this is about where the  
parenthesis go -- not *if* -- but where.
- we could always allow parenthesis to be dropped when the yield is  
the entire expression of an expression statement or the right-hand  
side of an assignment.
- in my experience with JS 1.7 I almost always had to parenthesize the  
yield expression when it was in some other kind of expression.  An in  
the cases where parenthesis weren't required, I parenthesized anyway  
to avoid ambiguity and maintain coding style consistency.  (And  
because I got tired of predicting incorrectly whether or not parens  
would be required in a particular context.)

So I would argue that there are two syntactical forms of yield, yield  
E  and (yield E), and that the rules regarding the requirement for  
parenthesis are hard to predict (from personal experience).   
Therefore, I argue that it would make sense to simplify a bit:
- the yield E form may be used when it is the entire expression of an  
expression statement
- all other times it must be parenthesized

Which is *kind of* a way of saying, if you're ignoring the send value,  
you don't have to parenthesize.  But if you use the send value, you  
must parenthesize.

And now that we've made clear the definition of parenthesized and non- 
parenthesized forms of yield, we can proceed to argue that yield(E) is  
a valid form of parenthesis, as much so as (yield E).

Pros for yield(E):
- backward compatible
- easier to read (to my eye)
- it "feels" more correct to me in context of the when-using-send- 
value rule

Pros for (yield E):
- consistent with python
- doesn't present any is-it-a-function? ambiguities



More information about the es-discuss mailing list