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

Functional Language Features in Rust – Iterators and Closures

rust-lang.github.io

Post reply on HN
Print view View original

31–40 of 42 posts

Re: Functional Language Features in Rust – Iterators and Closures

#31

Post by dozzie »

Rusky wrote: post #18
dozzie wrote: post #10

Earlier quoted context omitted.

OK, but if you avoided calling non-functional patterns part of functional programming, you would avoid invoking the topic of "what constitutes functional programming" altogether.

OK, but if you avoided disputing the definition of a word the author explicitly said was irrelevant, you would avoid invoking the topic of "what constitutes functional programming" altogether.

Thank you for pointing out that the word was irrelevant (and thus should not have been used in the first place).

Re: Functional Language Features in Rust – Iterators and Closures

#32

Post by dozzie »

steveklabnik wrote: post #11
dozzie wrote: post #10

Earlier quoted context omitted.

OK, but if you avoided calling non-functional patterns part of functional programming, you would avoid invoking the topic of "what constitutes functional programming" altogether.

What specifically does "functional programming" mean to you and why do these features not qualify?

Certainly functional programming is not making the data containers to fulfil a separately defined interface. This comes from OOP paradigm (its form that is implemented in most languages).

And then, what specifically does "functional programming" mean to you that makes implementing an interface a feature from functional paradigm?

But this all misses the point of my comment. If you knew it would invoke the unnecessary discussion to call the iterator "functional feature" (as the quoted comment signifies), you should have rephrased the title of the chapter in the first place, rendering the disclaimer unnecessary.

Re: Functional Language Features in Rust – Iterators and Closures

#33

Post by steveklabnik »

dozzie wrote: post #32
steveklabnik wrote: post #11

Earlier quoted context omitted.

What specifically does "functional programming" mean to you and why do these features not qualify?

Certainly functional programming is not making the data containers to fulfil a separately defined interface. This comes from OOP paradigm (its form that is implemented in most languages). And then, what specifically does "functional programming" mean to you that makes implementing an interface a feature from functional paradigm? But this all misses the point of my comment. If you knew it would invoke the unnecessary…

You didn't answer my question.

Re: Functional Language Features in Rust – Iterators and Closures

#34

Post by TheCycoONE »

bigger_cheese wrote: post #12

That was really well written. As I was reading through the example code in the section about closures let add_one = |x| x + 1; let five = add_one(4); I thought to myself "hmm I wonder what happens if I were to call the code with a float rather than an int?" Answered my question a few paragraphs down. Kudos. Is it possible to write a generic closure? i.e something that would add 1 to any numeric type.

The whole new Rust Book is quite well written. It was my first resource when I read it a few months ago and I found it easy to understand everything it covered - even lifetimes which I completely failed to get from the original book or other online resources. I look forward to the rest of the chapters being filled in.

Re: Functional Language Features in Rust – Iterators and Closures

#35

Post by pitaj »

curun1r wrote: post #25

Under the "Improving our I/O Project" section, there's this little paragraph: It would be nice if we could use ? on the Option returned from next, but ? only works with Result values currently. Even if we could use ? on Option like we can on Result, the value we would get would be borrowed, and we want to move the String from the iterator into Config. It seems remiss to not mention that Option/Result have combinators…

Please don't quote with code blocks.

Re: Functional Language Features in Rust – Iterators and Closures

#36

Post by dozzie »

steveklabnik wrote: post #33
dozzie wrote: post #32

Earlier quoted context omitted.

Certainly functional programming is not making the data containers to fulfil a separately defined interface. This comes from OOP paradigm (its form that is implemented in most languages). And then, what specifically does "functional programming" mean to you that makes implementing an interface a feature from functional paradigm? But this all misses the point of my comment. If you knew it would invoke the unnecessary…

You didn't answer my question.

I did, at least the relevant parts of your question. And it still stands that you missed my point that you just created a contention point fully knowing that it is useless contention (your quoted remark from the chapter prooves both that you knew it will be problematic and that you didn't need it there).

Re: Functional Language Features in Rust – Iterators and Closures

#37

Post by curun1r »

pitaj wrote: post #35
curun1r wrote: post #25

Under the "Improving our I/O Project" section, there's this little paragraph: It would be nice if we could use ? on the Option returned from next, but ? only works with Result values currently. Even if we could use ? on Option like we can on Result, the value we would get would be borrowed, and we want to move the String from the iterator into Config. It seems remiss to not mention that Option/Result have combinators…

Please don't quote with code blocks.

Umm...If I don't quote the entire code snippet, I'll end up with just the indented lines being quoted...the joys of HN formatting.

Re: Functional Language Features in Rust – Iterators and Closures

#38

Post by pitaj »

curun1r wrote: post #37
pitaj wrote: post #35

Earlier quoted context omitted.

Please don't quote with code blocks.

Umm...If I don't quote the entire code snippet, I'll end up with just the indented lines being quoted...the joys of HN formatting.

I was speaking with reference to "It would be nice..." which you quoted using a pre/code block (prepending four spaces). Please only use that for actual code, and use `>` at the start of the line to signify a quote, like so:

> Umm...If I don't quote the entire code snippet, I'll end up with just the indented lines being quoted...the joys of HN formatting.

This allows for responsive formatting on different screen sizes, and is especially beneficial for mobile users.

Re: Functional Language Features in Rust – Iterators and Closures

#39

Post by ben0x539 »

frankmcsherry wrote: post #24
steveklabnik wrote: post #11

Earlier quoted context omitted.

What specifically does "functional programming" mean to you and why do these features not qualify?

> In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. from https://en.wikipedia.org/wiki/Functional_programming I totally agree that neither iterators nor 2/3s of closures are "functional programming". That's fine, though,…

`FnMut` just means that the iterator methods don't artificially restrict the user-supplied closures. `map` itself doesn't become impure just because you can map `|x| { counter += x; x+1 }` over your list if you really want to.

I think it's fair to say that iterator methods are typically used as combinators to build computations out of pure functions to avoid having to manage mutable state.

Re: Functional Language Features in Rust – Iterators and Closures

#40

Post by sixbrx »

dozzie wrote: post #32
steveklabnik wrote: post #11

Earlier quoted context omitted.

What specifically does "functional programming" mean to you and why do these features not qualify?

Certainly functional programming is not making the data containers to fulfil a separately defined interface. This comes from OOP paradigm (its form that is implemented in most languages). And then, what specifically does "functional programming" mean to you that makes implementing an interface a feature from functional paradigm? But this all misses the point of my comment. If you knew it would invoke the unnecessary…

No OO style interfaces here, Ierator and IntoIterator are traits, which are more akin to a type class from Haskell than an interface as seen in OO languages
Post reply on HN