On Nov 21, 2010, at 7:21 PM, Chris Sells wrote:
> I'm a huge fan of iterators. As far as index goes, I'm not a fan of the use
> of the colon. We should take our time, but something that I wanted to throw
> into the pot would be to build on the key-based nature of for-in with syntax
> like this:
>
> forvals ( var x in xs ) {...}
>
> Also, have we given any thought to making it easier to implement custom
> iterators ala the C# "yield return" operator?
We've prototyped and shipped generators based on Python 2.5 (with a
simplification that avoids introducing GeneratorExit) for years, in
SpiderMonkey and Rhino. The yield operator is a low-precedence expression
prefix whose presence in a function makes it a generator. Wiki link:
http://wiki.ecmascript.org/doku.php?id=strawman:generators&s=generators
This strawman wil be revised based on specific feedback ("put something in the
function preamble, not just yield expressions in the body, to make it clearly a
generator", and the yield-in-try-with-finally argument), and prepared for
discussion at the January 2011 TC39 meeting.
/be
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Brendan Eich
> Sent: Sunday, November 21, 2010 7:05 PM
> To: Waldemar Horwat
> Cc: Mark S. Miller; es-discuss
> Subject: Re: Nov 18 notes
>
> On Nov 18, 2010, at 4:08 PM, Waldemar Horwat wrote:
>
>> Consensus that we should have iterators.
>
> For this, after all these years (JS1.7 added meta-programmable for-in in
> 2006), I'm grateful, although I wanted to add something your notes did not
> report:
>
> To get consensus, we made a tentative agreement to leave for-in as it was and
> not enable any meta-programmability of it, consigning it to the
> historically-underspecified and non-interoperable enumeration mystery-meat
> status.
>
> Instead, we did the committee-plays-it-safe thing of inventing new syntax for
> meta-programmable iteration:
>
> for (var i : x) ...
>
> This is a break from Python and JS1.7+ in SpiderMonkey and Rhino -- although
> it matches very late Java and C++ extensions that are similar (but not the
> same), and really not relevant to JS.
>
> Worse, the use of colon in this new for syntax is confusingly similar to
> long-standing future-proofing intentions around runtime type annotations (aka
> guards or contracts).
>
> (BTW, I don't think :: is a good type annotation or guard punctuator, btw --
> it's the C++ namespace qualification operator, also specified for namespacing
> by ECMA-357 (E4X) and used that way in ActionScript 3 (and in ES4, RIP). So I
> was surprised to see :: used for annotation-like syntax in
> http://wiki.ecmascript.org/doku.php?id=strawman:guards and
> http://wiki.ecmascript.org/doku.php?id=strawman:trademarks.)
>
> for (var i : x) ... // must be new iteration
> for (var i : T : x) ... // iteration again, but parsed how?
> for (var i : T in x) ... // for-in with annotated var
>
> Depending on what T might be, grammatically, this could get sticky for
> top-down parsers. It is confusing and ugly in any event, IMHO.
>
> Probably we need to take our time and not rush into a meta-programming-here
> syntax variant of for-in. I'll not propose anything better right now.
>
> /be
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
