On Jun 8, 2012, at 1:39 PM, Jay Freeman (saurik) wrote: > Hello. I am not 100% certain that this is an appropriate place to bring this > up, and I'm likewise not 100% certain that this is the kind of feedback that > is even warranted, nor am I 100% certain that this hasn't already been > discussed. However, I am at least fairly confident about all of these things > (sadly, the least confidence is in the latter, as I found this difficult to > search for due to terms like "in" and "of" ;P).
Feedback is always welcome and this is the place for discussions. Actual bugs in a specification draft should be reported at bugs.ecmascript.org > ... > > First, in the ECMA6 draft (I'm looking at the one from May 4th, for > reference), an ArrayComprehension can be used in the same place that an > ArrayLiteral can be used; however, ArrayComprehensions start with an > arbitrary Expression while ArrayLiteral is defined to be its own (as in, not > sharing productions with Expression) list of AssignmentExpressions. The ArrayComprehension material in that draft is incomplete. It's an initial cut at integrating the comprehension grammar is all that is really there. It may well be that the initial Expression of the ArrayComprehension productions should be an AssignmentExpression in order to avoid commas. > > This means that a lot of lookahead is required of the form that ECMAScript's > grammar seems to purposely avoid (based on previous conversations I've seen > on this mailing list; I might, however, be mistaken on this point). Even if > this is not the case, though, I will also argue that the resulting syntax is > fairly confusing to look at ;P. > > [a, b, c, d for x of q] > > Is the intention that the above syntax is to be allowed? I would presume that > if it were, the result would be roughly equivalent (modulo side-effects of a, > b, and c) to just using "d" for that expression, but I can also see people > finding that confusing (and instead expecting to get an array that starts > with a, b, and c, or an array with four times as many elements as q). It isn't clear. The original wiki proposal had expression in its grammar. However, I'm with use, even if it didn't complicate parsing the above seem unnecessarily confusing. AssignmentExpression looks to me like a better choice. > > (Of course, it could also be said that this feedback is quite "too early" and > this is already known and obvious, given that the semantics for array > comprehensions hasn't even been added to the specification yet. ;P I'm sorry > if this is a bother, then.) > > The same syntax choice has been used for the list to iterate over. In this > position it does not cause any grammar issues, but it still causes some > syntax that I have a difficult time imagining that people will make the right > assumptions about. > > [a, b, c, d for x of 1, 2, 3, 4] Like you say, no grammar issues here but it does look confusing. Again, AssignmentExpression may be a better choice. > > Finally, I have a user who is currently using JS1.7 array comprehension > syntax (which I also currently support), but his use case isn't actually > solved by the current syntax for ECMA6 array comprehensions as he's using > for-in iteration, not for-of iteration (filtering the keys of an object for > purposes of a reflection browser). > > I realize that he could have a helper function that took an object and > returned an array of its keys, but is there a reason to not make the syntax > for array comprehensions match the possibilities of normal iteration? I can > see many people being surprised that for-in does not work in this context > (and it does not seem to cause any in-related grammar issues). We've generally been thinking of for-in as an obsolete form and new code should use for-of. The iterator (for-of) proposal includes a set of such functions; http://wiki.ecmascript.org/doku.php?id=harmony:iterators#standard_api The intent is that these will be included in the Es6 spec. Allen
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
