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