User talk:Hout

Restored this on the grounds that it matches all three of the stated requirements:

- They should be distinct from (nested) for loops within the syntax of the language. - They should return either a list or an iterator (something that returns successive members of a collection, in order). - The syntax has parts corresponding to that of set-builder notation.

It uses no for loops, returns a list, and has the parts corresponding to set-building notation.

The previous alternative is useful, but is restricted to a smaller subset of JavaScript, and arguably uses for loops.

If we are to delete one, we should delete both, but I am not sure that either approach has much value.

Both examples are illustrative of such resources as JavaScript is currently able to provide for patterns of this kind.

Hi Hout, unfortunately map & filter are the other way of doing things that are not list comprehensions. map&filter are arguably as well known a method as list comprehensions and some languages have both map & filter and list comprehensions as part of the language. The wp:List comprehension article also makes the distinction up front. Maybe I should add that fact to the task? --Paddy3118 (talk) 20:16, 7 September 2015 (UTC)

Clearly JavaScript 1.6 lacks built-in list comprehension syntax, and I understand your point, but this raises the issue of the value and purpose of of the Wiki. I would argue that users of Javascript seeking to solve the kind of problems that are addressed by list comprehension are better served by an example of how the resources of the language can be used than by a blank page.

Deletion might be intelligible if the purpose of the wiki was the support a narrow language partisanships or evangelisms ('my language has better built-in support for this than yours') but not if it is a public resource aiming to help those who look up a particular language under a particular heading.

If we were to delete that example, we would really also have to delete the preceding JavaScript example too (it uses a kind of for loop), and also the Mathematica example which is syntactically and formally identical. I am not sure that a chain of such deletions would really seem particularly constructive and helpful to users.

To concretise, why, for example, should we 'allow' users to find and reflect on the current Mathematica example:

<lang Mathematica>Select[Tuples[Range[100], 3], #11^2 + #12^2 == #13^2 &]</lang>

but not line 1 of the second JavaScript example:

<lang JavaScript>select(nTuples(range(1, 100), 3), function ([x, y, z]) {

   return x * x + y * y === z * z;

});</lang>

These two forms are clearly isomorphic, but more importantly, they are both clearly of relevance and potential interest to users.

Hi Hout. This task is specifically about list comprehensions as a syntactic construct. It could have been about select statements where it would not suffice to get the result using if/elif.../elif/else blocks - again they may be isomorphic as you say but we want the construct asked for not merely a way to get the answer. map& filter can get the result but it is not what is asked for. --Paddy3118 (talk) 21:08, 7 September 2015 (UTC)