newbie

Brendan Eich brendan at mozilla.com
Wed Nov 30 23:58:20 PST 2011


On Nov 30, 2011, at 10:39 AM, Anton Yatsenko wrote:

> Comprehensions in sense of arrays [x*y for x of .. for y of ..] with array as a result is pretty clear, on the other hand — everything is expression in (), and my gut (hi Doug) told me any possible thing, but not an object. That's why my first thought was about {}.
> 
> From readability point of view if generator comprehension returns object it should be in {}, if array — [], actual value or function expression — () // IMO

{} is an Object instance. (i for i in range(n)) is a generator iterator, nothing like an Object instance -- much more specific. There's no reason to use { instead of (.


> From grammar point of view — {} overloading is a big problem, once we'll do it for the first time — we'll continue to put features and this is dead end.

Right.


> Probably it's better to not use () comprehension at all?

The () are not required in all cases. Consider how verbose Peter Norvig's sudoku solver ported to JS1.8 (https://bug380237.bugzilla.mozilla.org/attachment.cgi?id=266577) would be without generator expressions:

function assign(values, s, d) {
    if (all(eliminate(values, s, d2) for (d2 in values[s]) if (d2 != d)))
        return values
    return false
}


The actual parameter to the all call is a generator expression, which is important to avoid exponential blow-up -- using an array comprehension fails to cut off doomed searches via constraint propagation.

Deny JS the generator expression special form, and you require this:

function assign(values, s, d) {
    if (all(function () { for (let d2 in values[s]) if (d2 != d) yield eliminate(values, s, d2); }()))
        return values
    return false
}


Strictly less readable. People who know generators can perhaps parse it. The generator lambda could be hoisted and declared, but that burns lines and a name.

Coming at a language as a newbie and being burned by an idiom can be not fun, or even calamitous. On the other hand people use and create idioms all the time. In this case the idiom is related to array comprehensions and for-in loops. It's not completely new and different.


> Kind of a way to avoid misunderstanding and safe {} for literals and blocks only.

There's no misunderstanding a generator expression, since 'for' is not an infix operator in JS without generator expressions.

Norvig's constraint-propagation-based solver shows good use of both array comprehensions and generator expressions. You need both: array comprehensions for eager lists, generator expressions for lazy lists.

/be


> 
> Anton.
> 
> P.S. 
>>   var o = { [f(x)]: 12 };        // object literal with property name computed from f(x)
> I really need this feature for a while :)
> 
>>   var g = { [f(x)] for x of a }; // generator producing a sequence of singleton arrays containing f(x)
> 
> this kind of syntax probably should not be implemented ever
> 
> 
> On Nov 30, 2011, at 7:45 PM, David Herman wrote:
> 
>> On Nov 30, 2011, at 7:14 AM, Anton V. Yacenko wrote:
>> 
>>> It's interesting to me why () syntax returns object, and why not {}.
>> 
>> I assume you're talking about generator expressions, which have the syntax of array comprehensions but using parentheses as their outer delimiter. The idea originally came from Python, which uses parentheses for generator expressions.
>> 
>> Using {} is an interesting idea, but it could be tricky to fit that into the grammar, because of the overlap with object literals. Brendan has experimented with the idea of allowing overlap between different {} forms in other contexts:
>> 
>>   http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal
>> 
>> In another discussion about do-expressions:
>> 
>>   http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions
>> 
>> we talked about the possibility of allowing block statements as expressions:
>> 
>>   var g = { let x = f(); x * x };
>> 
>> and Allen Wirfs-Brock raised objections that allowing overlap between object literals and objects whose contents can be expressions will be a problem for human readers, even if formally unambiguous:
>> 
>>   https://mail.mozilla.org/pipermail/es-discuss/2011-November/018257.html
>> 
>> This issue will get worse as we work on extending the grammar of object literals, for example to allow computed property names in square brackets. In the context of generator expressions, this would lead to subtle differences like:
>> 
>>   var o = { [f(x)]: 12 };        // object literal with property name computed from f(x)
>>   var g = { [f(x)] for x of a }; // generator producing a sequence of singleton arrays containing f(x)
>> 
>> Put differently: we already overload the { } syntax for block statements and object literals, and we use the context to disambiguate. Overloading them further, especially within the same context, would lead to visual confusion.
>> 
>> Dave
>> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111130/33d17181/attachment.html>


More information about the es-discuss mailing list