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

[Brendan Eich]

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  
implementors.

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).

/be