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

Neil Mix nmix at pandora.com
Sun May 17 19:00:40 PDT 2009


As a follow on to my argument I would cite two examples for why it  
would be good to always require parenthesis when the send value is used:

Example 1 I saw somewhere else in this thread:

yield a ? b : c

Is it
   (yield a) ? b : c   |   yield(a) ? b : c,
or
   (yield a ? b : c)   |   yield(a ? b : c)


example 2:

let x = yield-5;

is that
   let x = (yield) - 5;   |   let x = yield() - 5;
or is it
   let x = (yield -5);    |   let x = yield(-5);

I know the rules for both examples are very clear, but programmers  
don't always read the specs. :P  To someone not intimately familiar  
with JS order of precedence, either one presents ambiguity (or worse,  
doesn't!)  Why play with fire?

On May 17, 2009, at 8:39 PM, Neil Mix wrote:

>
> 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
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list