yield syntax (diverging from: How would shallow generators compose with lambda?)
brendan at mozilla.com
Thu May 14 13:48:33 PDT 2009
On May 14, 2009, at 1:14 PM, Neil Mix wrote:
> On May 14, 2009, at 2:38 PM, Brendan Eich wrote:
>> Indeed the low-precedence (same as assignment) nature of the yield
>> unary caused JS1.7 to follow Python in requiring parentheses around
>> yield expressions in lists: in comma expressions and actual
>> parameter lists (although we diverged from Python by allowing an
>> unparenthesized yield expression as the last actual argument in a
>> call or new expression's parameter list -- Python requires
>> foo((yield bar)) instead of foo(yield bar)).
> I have this idea that it would be better for yield expressions to
> look like function calls: 'yield' '(' expression? ')'. (Note that
> this is only a syntactical suggestion; clearly an implementation
> wouldn't actually treat it like a function.) That would eliminate
> the precedence issues Brendan cites while also making the syntax
> backward compatible with earlier ES parsers. Is there any technical
> reason why that wouldn't be possible?
The syntax could work but we need to reserve yield contextually. It
can't be a user-defined function name and a built-in function. The
compiler must unambiguously know that yield (the built-in) is being
called in order to make the enclosing function a generator.
This is reason enough in my view to keep yield a prefix operator and
reserve it. I wish I had done that with eval in JS1.0!
Another reason is your duck/cow point, which I think is a separate
point from compiler analyzability. Really, no one writes yield(...) in
Python, and extra parens hurt (I know RSI sufferers who benefit from
lack of shifting in Python and Ruby).
Now you could argue that we have eval already, and a cheap-ish way to
detect direct calls to it (see https://mail.mozilla.org/pipermail/es-discuss/2009-January/008656.html)
, so why not add something like that again? One reason is that the
cost is not zero -- cheap-ish, not cheap and not free. Adding more
distinguished special-form instructions that fall back on call
behavior if the callee is not the magic built-in will annoy
But you do make a good no-new-syntax case, ignoring the above
considerations. I still don't buy it, given let not being doable the
same way. We need new keywords and special forms (not many, but it's
absurd to freeze the set from ES3 in 1999).
More information about the es-discuss