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