On May 17, 2009, at 5:05 PM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On May 17, 2009, at 12:43 PM, Mark S. Miller wrote:
On Sun, May 17, 2009 at 11:00 AM, Brendan Eich <bren...@mozilla.com>
wrote:
Analogous to direct vs. indirect eval in ES5 (15.1.2.1.1), there
is no
purely syntactic specification for what Neil proposes. A runtime
check is required. So I don't see why you are focusing only on
syntax here.
I don't follow. What runtime check? For the eval operator, the
runtime
check is whether the value of the eval variable is the original
global
eval function. It makes no sense to have a corresponding global
yield
function value.
If we reserve yield then you're right. One of the appealing (at
least to
me) aspects of Neil's suggestion was that it would avoid opt-in
versioning required by reserving yield (which is used in extant web
content, or was when we tried reserving it without opt-in
versioning --
the particular use was as a formal parameter name, used as a flag
not a
function).
Oh, right. We've been talking at cross-purposes. I assumed that you
were
suggesting that 'yield' should be contextually reserved.
Oh, I should have seen that. Thanks for clarifying.
That is what
I've been saying couldn't work due to ambiguities.
RIght, no sane way to reserve yield or another keyword contextually
(e.g., only in callee position; "contextually" in the sense of get and
set in object initialisers).
In JS1.7+, we reserve yield with opt-in version selection via <script
type="...;version=1.7"> and the like. In such a script, yield and let
are reserved the same way the other identifiers are, which is how ES5
does it (with an extension we've discussed -- the extension where a
reserved identifier can be used after 'function' -- but that's not
interesting for this discussion).
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
