March 28 meeting notes

Mark S. Miller erights at
Thu Mar 29 13:36:32 PDT 2012

In order to avoid contributing to the list of "exceptions to TCP for
non-rejected programs", we need to reject "yield" in these positions. And
it is upwards compatible since arrow functions are new. And as you observe,
less confusing.

With such a "yield" prohibited, AFAICT the exceptions in non-rejected
programs are "return" and the open question about "var". Did we miss any

On Thu, Mar 29, 2012 at 1:26 PM, Brendan Eich <brendan at> wrote:

> Andreas Rossberg wrote:
>> For me, the biggest blow against TCP lambda forms in general was Mark's
>> observation regarding the incompatibility with 'yield' that you mention in
>> the other post.
> It seems 'yield' may be a red herring. We all forgot that it is
> contextually defined as a keyword only in generator functions, which have a
> distinguished head (* after function or before method name).
> Arrows cannot be generator functions, so yield is not reserved in arrow
> bodies. It need not be illegal, though. But probably it's best to ban just
> to avoid confusion:
> function yield(e) { return 42; }
> function* gen() {
>  yield (v) => yield(v);
>  yield 99;
> }
> The yield call after the =>, if not an error as the arrow function syntax
> proposal has it now, would call the outer yield function.
> /be
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list