On May 14, 2009, at 5:13 PM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On May 14, 2009, at 1:14 PM, Neil Mix wrote:
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.
But that doesn't help: the argument to yield is an arbitrary
expression,
so 'yield (foo)' could be either a function call or a yield-
expression.
That means that this approach can at best be no simpler to implement
or
specify than the function call syntax.
Were you responding to Neil instead of me? I'm not advocating Neil's
proposal, but it seems to me he's arguing for it to avoid the
mandatory parentheses around the entire yield expression in almost any
surrounding expression in which it could be embedded. He is right that
requiring parentheses around yield's operand avoids mandatory parens
around yield expressions in list contexts.
Simpler to implement is not the issue, but it's a wash as you say.
With the function call syntax, it would be sufficient to keep the
existing ES5 grammar for function calls, and then check after parsing
whether a MemberExpression or CallExpression followed by Arguments is
the string "yield". With the operator syntax, it's more complicated
than that because there are more syntactic contexts to consider.
Yes, but it's not that complicated. SpiderMonkey and Rhino do it. Code
size burden is in the noise.
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).
Yes, those are separate points that I am not arguing against here.
Ok.
I was replying to Neil, not to you (hadn't seen any message from you
on this sub-thread).
/be
--
David-Sarah Hopwood ⚥
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
