5 ms·

I really dislike the proposed way to do this. If this is "Swifty", give me something else. The Haskell list comprehension made sense to me the first time I saw

I really dislike the proposed way to do this. If this is "Swifty", give me something else. The Haskell list comprehension made sense to me the first time I saw it, but there is no way I'd know what the mess in the article was doing until someone explained to me. Design has to come first. You can't just go with what's "Swifty" if that doesn't convey what's happening in a reasonable fashion.

douglaswlance 9y ago
Do you know Swift...?
- 59nadir 9y ago
  No, but I didn't know Haskell the first time I saw a Haskell list comprehension either, and it still made perfect sense. The proposed Swift solution just looks like Perl level line noise. The only good thing about it is the processing being done in a block at the end.
coldtea 9y ago
>The Haskell list comprehension made sense to me the first time I saw it, but there is no way I'd know what the mess in the article was doing until someone explained to me. Given that this is basic Swift, the complaint makes no sense: let a = Array(1..<5, 3..<5, where: { n, _ in n % 2 == 0 }) { ($0, $1) } // [(2,3),(2,4),(2,5) ... let a = Array(1..<5, 3..<5) { ($0, $1) } // [(1,3),(1,4),(1,5),(2,3),(2,4) ...
- dozzie 9y ago
  What the heck? Why does it end up like this? I see very little connection, and I've seen list comprehensions in several different languages.
  - 59nadir 9y ago
    That's precisely it. It just looks like a bunch of noise and then there's a result. People complain about list comprehensions in several languages where at least there is a structure to them and they don't look like crap. I can't imagine what the Swift community would say about code clarity and usage recommendations with regards to this proposition.
  - rbehrends 9y ago
    A list comprehension is basically a cartesian product with a filter and map applied to it. What we have here is an array constructor, which takes one or more ranges as its arguments. The named `where:` argument provides the filter closure and the final argument is the map, using standard trailing closure syntax. In fact, other than the missing implementation of the constructor, this would be perfectly legal Swift code today. I'm not sure what's there to be confused about. `x..<y` describes an open range (including x, excluding y). `{x, y in ... }` is normal Swift closure syntax, where `x` and `y` are the arguments; you can also use positional arguments as in `{ ($0, $1) }` instead. If the final argument of a function is a closure, it can be (as in Ruby) be written after the closing parenthesis of the function call.
    - dozzie 9y ago
      > A list comprehension is basically a cartesian product with a filter and map applied to it. Ah yes, explain me more the concept I've been using for a dozen years, surely I don't understand it. And with mix of terminology from as far topics as set theory and functional programming, to lessen the confusion. > What we have here is an array constructor, which takes one or more ranges as its arguments. I would never have guessed the arguments thing. > `x..<y` describes an open range (including x, excluding y). I would never have guessed it's open range. > you can also use positional arguments as in `{ ($0, $1) }` instead. I would never have guessed, and I was writing in Perl with its magic variables for more than a half of my professional career and most of my studies. And that's the whole point: the syntax is so atrocious that it takes training to understand it. I can accept the semantics to need training to understand (as I did with Perl, Erlang, or now doing with Ada), but with this we haven't hit that level yet.
      - rbehrends 9y ago
        So, your problem is that Swift's syntax in general isn't to your tastes, not the list comprehension proposal as such? Fair enough, but that's not what you were saying.
        dozzie 9y ago

douglaswlance 9y ago

Do you know Swift...?

59nadir 9y ago
No, but I didn't know Haskell the first time I saw a Haskell list comprehension either, and it still made perfect sense. The proposed Swift solution just looks like Perl level line noise. The only good thing about it is the processing being done in a block at the end.

coldtea 9y ago

>The Haskell list comprehension made sense to me the first time I saw it, but there is no way I'd know what the mess in the article was doing until someone explained to me. Given that this is basic Swift, the complaint makes no sense: let a = Array(1..<5, 3..<5, where: { n, _ in n % 2 == 0 }) { ($0, $1) } // [(2,3),(2,4),(2,5) ... let a = Array(1..<5, 3..<5) { ($0, $1) } // [(1,3),(1,4),(1,5),(2,3),(2,4) ...

dozzie 9y ago
What the heck? Why does it end up like this? I see very little connection, and I've seen list comprehensions in several different languages.
- 59nadir 9y ago
  That's precisely it. It just looks like a bunch of noise and then there's a result. People complain about list comprehensions in several languages where at least there is a structure to them and they don't look like crap. I can't imagine what the Swift community would say about code clarity and usage recommendations with regards to this proposition.
- rbehrends 9y ago
  A list comprehension is basically a cartesian product with a filter and map applied to it. What we have here is an array constructor, which takes one or more ranges as its arguments. The named `where:` argument provides the filter closure and the final argument is the map, using standard trailing closure syntax. In fact, other than the missing implementation of the constructor, this would be perfectly legal Swift code today. I'm not sure what's there to be confused about. `x..<y` describes an open range (including x, excluding y). `{x, y in ... }` is normal Swift closure syntax, where `x` and `y` are the arguments; you can also use positional arguments as in `{ ($0, $1) }` instead. If the final argument of a function is a closure, it can be (as in Ruby) be written after the closing parenthesis of the function call.
  - dozzie 9y ago
    > A list comprehension is basically a cartesian product with a filter and map applied to it. Ah yes, explain me more the concept I've been using for a dozen years, surely I don't understand it. And with mix of terminology from as far topics as set theory and functional programming, to lessen the confusion. > What we have here is an array constructor, which takes one or more ranges as its arguments. I would never have guessed the arguments thing. > `x..<y` describes an open range (including x, excluding y). I would never have guessed it's open range. > you can also use positional arguments as in `{ ($0, $1) }` instead. I would never have guessed, and I was writing in Perl with its magic variables for more than a half of my professional career and most of my studies. And that's the whole point: the syntax is so atrocious that it takes training to understand it. I can accept the semantics to need training to understand (as I did with Perl, Erlang, or now doing with Ada), but with this we haven't hit that level yet.
    - rbehrends 9y ago
      So, your problem is that Swift's syntax in general isn't to your tastes, not the list comprehension proposal as such? Fair enough, but that's not what you were saying.
      - dozzie 9y ago