Array comprehensions shorter syntax (?)

Dmitry A. Soshnikov dmitry.soshnikov at
Sun May 29 12:52:51 PDT 2011

On 29.05.2011 23:29, Brendan Eich wrote:
> On May 29, 2011, at 7:17 AM, Jose Antonio Perez wrote:
>> 2011/5/29 Dmitry A. Soshnikov <dmitry.soshnikov at 
>> <mailto:dmitry.soshnikov at>>
>>     That's it, exactly. We always looking for a shorter sugar.
>>     Though, the main thing that the sugar shouldn't be cryptic at the
>>     same time. Probably Erlang's list comprehensions are cryptic for
>>     someone, but again, taking into account arrow-functions, seems
>>     arrow-comprehensions aren't so cryptic.
>> I think that your proposal based in Haskell's syntax is natural,clear 
>> and easy for the user. A EBNF grammar for it:
>> ListComprehension :  '[' Expression '|'  IterableOrFilter 
>> (,IterableOrFilter)+ ']'
>> IterableOrFilter:          Id '<-' ArrayOrGenerator | BooleanFilter
>> The problem is the LL(1) conflict with Array Literal, but that 
>> doesn't matter much, right?  ;)
> No, it's a big incompatibility that could result in no early error, 
> rather a shift in meaning.
> We're not doing those without a really good reason. We don't have one 
> here.

OK; it has been just proposed.

Basically I think paren-free "for-in + if" scheme is fine, just though 
it can be more sugared with the arrow. But, there's no a _big_ need, I 

P.S.: though, btw, IIRC, you said the same when an year ago I proposed 
arrow functions or Ruby's blocks and they were refused because of 
grammar reasons; today we want them to standardize ;) I mean, perhaps 
what seems not so needed and complicated to implement at first glace, 
later can become interesting and useful.


> People seem to forget that | is an operator in the language. In 
> I 
> worked around the lesser problem of parameter default values by 
> requiring any default value using bitwise-or to be parenthesized:
>   blam = {|x = (y | z)| x*x};
> But block-lambdas do not use [] where | may be an operator in a single 
> element initialiser expression, so there's no further incompatibility.
> Not so with square brackets.
> Array comprehensions using for-in or the replacement (paren-free, 
> probably "for-of") Harmony syntax are in for
> /be

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

More information about the es-discuss mailing list