On Nov 22, 2010, at 11:35 PM, Brendan Eich wrote: > On Nov 22, 2010, at 11:19 PM, Maciej Stachowiak wrote: > >>> 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. >> >> If the colon is less future-compatible than we like, why not: >> >> foreach (var i in x) > > All the new words are not reserved, so they could begin a function call > expression in extant code: > > hi = "there" > foreach (i in x) > print(i) > > means > > hi = "there"; foreach(i in x); print(i); > > today. Same if you s/foreach/iterate/ or any non-reserved identifier. > Wherefore Allen's co-opting of enum (plus with, a decent preposition given > enum but 8 chars in two keywords hurt kittens everywhere).
One possibility is to add a space as apparently a few other languages do: for each (var i in x) Should be unambiguously parsable and easy to understand. > > Anyway, the bikeshed is secondary. We need to agree on what meta-programmable > for-in means with the enumerate trap (specified by the wiki pages on > harmony:proxies), how that changes with the optional iterate trap > (strawman:iterators), and when it might matter (for all for-in loops, or only > those in Harmony code?). Fair enough. Another important question is whether for..in should continue to guarantee that all values enumerated would be strings. Preserving that guarantee clearly makes for..in useless for the strawman:iterators purpose, but not for the harmony:proxies enumeration trap (and thus iterators would need new syntax to be usable). Breaking the guarantee may cause problems for existing code. Breaking the guarantee only in Harmony mode creates additional migration tax. Thus, iterators create a potential motive for new syntax that the proxy enumeration trap does not. Given this, it is useful to identify candidate syntax that doesn't have perceived showstopper problems, so that we can evaluate the tradeoffs among the three prongs of the trilemma. (As an even more concrete previously mentioned example, a new syntax allows sane defaults for arrays without breaking compatibility for the existing construct.) Regards, Maciej _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
