yield syntax

[Brendan Eich]

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