User talk:Hout: Difference between revisions

Content added Content deleted

Inline

@@ Line 1: / Line 1: @@
-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? --[[User:Paddy3118|Paddy3118]] ([[User talk: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], #1[[1]]^2 + #1[[2]]^2 == #1[[3]]^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. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 21:08, 7 September 2015 (UTC)
-I think we need to consult more broadly, to see how widely your understandable but perhaps slightly zealous appetite for deletion is felt to add value, rather than eroding it. Remember that when you asked to be allowed to do this kind of thing in the Discussion page, you were counselled to restrain yourself and restrict your targets to examples which relied on 'for loops'.  This is not one of those examples. It uses functional set construction.
-:Does it use a list comprehension? I think you must agree that it does not. In fact, this: [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Array_comprehensions] might give Javascript list comprehensions in 2016. If you had an interpreter with the feature you might state that the feature is experimental, give the link and code the task example and run it.
-:The language spec I guess for now says that list comprehensions are missing but may be on the way. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 21:40, 7 September 2015 (UTC)
-Yes, it writes a list comprehension, precisely as requested, and precisely in the manner that will be most helpful and instructive to current JavaScript 1.5 and 1.6 users who
-. need to write a list comprehension,
-. want help with writing one in JavaScript, and
-. turn to Rosetta Code for help.
-We may still be waiting for syntactic sugar for list comprehensions in JavaScript, but we can write them in any Turing-complete language which supports higher-order functions. All syntax "just rewrites" lambda applications. Even in Haskell the list comprehension syntax desugars down to Haskell's lambda primitives.
-The syntax in which I have written that list comprehension is identical to that of the Mathematica example:  a boolean lambda applied to a functional set construction, and that is precisely what lies under *all* the various syntactic sugars in which list comprehensions can be written, without nested for loops, in any language in which they can be written, including in JavaScript.
-Your proposal would, inadvertently of course, have no other effect than to prevent users of JavaScript from using Rosetta Code to find out how to do that.
-Is that really what you want ? I wonder if some slight confusion has arisen in your mind about the nature and structure of compilers and interpreters ?
-: I think that filter, with an appropriate generator, satisfies the requirements of the list comprehension task. I think that requiring syntax instead would violate the [[Rosetta_Code:Add_a_Task#Task_focus|Task focus]] aspect of Rosettacode. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 23:25, 7 September 2015 (UTC)

Latest revision as of 17:32, 18 March 2021