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.

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) ...

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.

Let me rephrase then: what you seemed to be saying.

> ...you should get off your high horse. Your juggling with math terminology earlier is not impressive.

I'm not sure where you got that impression. I learned about Cartesian products in high school. Everything else I was talking about is at most first year computer science stuff.

I was simply trying to be precise, using the most basic terminology I could think of.

Apparently you don't, as you appeared confused. Whether it was just the syntax of Swift that confused you, or something more general, the parent was not a medium to know.

In any case, the parent gave a general answer. If you already know some parts of the answer, you can skip them (others might not, and can find it useful) -- no need to be rude about it.

>I would never have guessed the arguments thing.

So? Tons of things a programming language does are not guessable if you don't know its semantics, and even less so if you also don't know its syntax. That doesn't even make them bad or difficult, just not already familiar.

>I would never have guessed it's open range.

I would. .. and ... are very common ways to describe ranges, and < is a logical thing to use to say it's open given its math meaning.

>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.

Well, I would have guessed all 3 of them. $0, $1 and the like are quite common, and at that place they couldn't be anything else but positional arguments.

>And that's the whole point: the syntax is so atrocious that it takes training to understand it.

Or it's so good that it takes training to understand it, as opposed to catering to the lowest common denominator of what people can immediately "guess".

⇒ Generator expressions are the way to go. They would give you the sequence of elements without generating the (potentially enormous) data structure.

From there, methods to reify the items in a sequence would give you your list, array, or dictionary, where needed.

So, for Swift, I wouldn’t use

    Array(1..<5, 3..<5) { ($0, $1) }

    Array(for i in 1..<5, j in 3..<5 yield (i,j))

Neither is an improvement over the other. Sometimes it's more important to have the results up front fast, sometimes generating them on demand is better.

This.

> Nothing except local variable names (and nested macro capture names) is hygienic in macro_rules in fact.

It's a thing that's being fixed in the new macro systems, yeah.