Nov 18 notes

Andreas Gal andreas.gal at gmail.com
Tue Nov 23 00:24:17 PST 2010


On Nov 23, 2010, at 12:11 AM, Maciej Stachowiak wrote:

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

Why? The primary reason for the iterator protocol is avoiding eager instantiation of the entire result set. If we force stringification in for-in when used with an iterator, the protocol is still alive and well and useful.

We could avoid stringification if next() is called on iterators directly, or provide an additional distinct new for-each or whatever syntax that doesn't stringify.

Andreas

> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list