On Oct 12, 2011, at 5:28 PM, Dean Landolt wrote:
> On Wed, Oct 12, 2011 at 5:08 PM, Brendan Eich <[email protected]> wrote:
> On Oct 7, 2011, at 6:51 AM, Mikeal Rogers wrote:
>> I wonder why the semantics of generators can't be achieved in a way that is
>> clearer to less than expert programmers.
>
> What's the problem? You didn't say.
>
> The semantics of generators must be such that the compiler can tell when a
> function is a generator. So something is going to signify "this function is a
> generator".
>
> (We already went around the block with using "generator" as a keyword --
> that's not a reserved future word so it would need to be reserved as a
> breaking change, or possibly only if it comes after a line terminator, but
> then anonymous generators are still incompatible. I.e., you could have JS
> today of this form:
>
> x =
> generator
> (a, b)
> {
> }
>
> which if generator names a callable object and a and b are bound, is
> perfectly legal.)
>
> You have to admit, this is highly unlikely.
It's not a matter or likelihood. We need a backward compatibility (apart from
five fingers of fate, four of them giving early errors on incompatible code
migration). We need an unambiguous grammar. And we need usable syntax. Adding a
[no LineTerminator here] generator ... production fails two of those three.
> But this reminds me -- has anyone proposed a method shorthand for generators?
Yes, it's easy:
var x = {
*foo() { yield ... }
}
The * goes after 'function' and before the optional name, in the current
proposal. So for method shorthand, where there is no 'function' but there must
be a name, the * goes before the generator method's name.
This is yet another problem (after [computedNameExpr]:...) for making commas
optional, as discussed.
/be_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
