brendan at mozilla.com
Sun May 17 17:32:46 PDT 2009
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 <brendan at mozilla.com>
>>>> Analogous to direct vs. indirect eval in ES5 (188.8.131.52.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
>>> check is whether the value of the eval variable is the original
>>> eval function. It makes no sense to have a corresponding global
>>> 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
> Oh, right. We've been talking at cross-purposes. I assumed that you
> 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).
More information about the es-discuss