Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

List Comprehension in Swift

duan.ca

Post reply on HN
Print view View original

21–30 of 32 posts

Re: List Comprehension in Swift

#21

Post by 59nadir »

douglaswlance wrote: post #15
59nadir wrote: post #10

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.

Do you know Swift...?

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.

Re: List Comprehension in Swift

#22

Post by 59nadir »

dozzie wrote: post #19
coldtea wrote: post #16

Earlier quoted context omitted.

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

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.

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.

Re: List Comprehension in Swift

#23

Post by rbehrends »

dozzie wrote: post #19
coldtea wrote: post #16

Earlier quoted context omitted.

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

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.

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

Re: List Comprehension in Swift

#24

Post by dozzie »

rbehrends wrote: post #23
dozzie wrote: post #19

Earlier quoted context omitted.

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.

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 cod…

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

Re: List Comprehension in Swift

#25

Post by rbehrends »

Someone wrote: post #13

List comprehension is a bad idea, IMO. They were an improvement over not having anything like it, but python has improved over it ( https://wiki.python.org/moin/Generators ) ⇒ 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 diction…

This does not require a different syntax. You'd just construct a lazy list instead of an array.

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.

Re: List Comprehension in Swift

#26

Post by rbehrends »

dozzie wrote: post #24
rbehrends wrote: post #23

Earlier quoted context omitted.

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 cod…

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

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.

Re: List Comprehension in Swift

#27

Post by dozzie »

rbehrends wrote: post #26
dozzie wrote: post #24

Earlier quoted context omitted.

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

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.

> Fair enough, but that's not what you were saying.

Then tell me, what was I saying?

>> I see very little connection, and I've seen list comprehensions in several different languages.

And then...

> So, your problem is [...] not the list comprehension proposal as such?

...you should get off your high horse. Your juggling with math terminology earlier is not impressive. I know you wanted to sound smart, but you overdid it and got smartass instead.

Re: List Comprehension in Swift

#28

Post by rbehrends »

dozzie wrote: post #27
rbehrends wrote: post #26

Earlier quoted context omitted.

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.

> Fair enough, but that's not what you were saying. Then tell me, what was I saying? >> I see very little connection, and I've seen list comprehensions in several different languages. And then... > So, your problem is [...] not the list comprehension proposal as such? ...you should get off your high horse. Your juggling with math terminology earlier is not impressive. I know you wanted to sound smart , but you overdi…

> Then tell me, what was I saying?

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.

Re: List Comprehension in Swift

#29

Post by saghm »

stevedonovan wrote: post #8
thewayfarer wrote: post #3

> (Can’t wait until we can have variadic generic parameters!) This.

It's a genuinely hard problem. There are proposals for Rust, but nothing actionable. Catching up with all the other cool things takes precedence. (side-note: Rust dodged the problem by using macros. As a C++ guy, I was a little uneasy with this, but they're _mostly_ hygenic)

Out of curiosity, what are the non-hygienic parts are of Rust macros? I'm pretty sure that non-procedural macros are hygienic, although I don't know a whole lot about the implementation of procedural macros.

Re: List Comprehension in Swift

#30

Post by steveklabnik »

saghm wrote: post #29
stevedonovan wrote: post #8

Earlier quoted context omitted.

It's a genuinely hard problem. There are proposals for Rust, but nothing actionable. Catching up with all the other cool things takes precedence. (side-note: Rust dodged the problem by using macros. As a C++ guy, I was a little uneasy with this, but they're _mostly_ hygenic)

Out of curiosity, what are the non-hygienic parts are of Rust macros? I'm pretty sure that non-procedural macros are hygienic, although I don't know a whole lot about the implementation of procedural macros.

Quoting the subreddit the other day:

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

Post reply on HN