How would one explicitly allocate space for a closure? (That is, in such a way that one could handle allocation failure.) I can't find any examples nor any hints about what the syntax might look like.
Functional Language Features in Rust – Iterators and Closures
21–30 of 42 posts
Re: Functional Language Features in Rust – Iterators and Closures
#22That 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.
Thanks! To answer your last question, not yet. There was an RFC for this, but it was recently postponed; closures rely heavily on traits and we are in the process of re-doing the internals of the trait system. If I remember the reason correctly.
Indeed, the way you would be generic over generic closures would be "type HRTB" (e.g. F: for Fn(&T) -> T), which depends on the trait system overhaul, just like ATC.
Re: Functional Language Features in Rust – Iterators and Closures
#23How would one explicitly allocate space for a closure? (That is, in such a way that one could handle allocation failure.) I can't find any examples nor any hints about what the syntax might look like.
Closures are stack allocated unless you wrap them in something like a Box, so it's up to you. They're no different than any other value.
Re: Functional Language Features in Rust – Iterators and Closures
#24Earlier 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?
> 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, because I really enjoy the sane way that it all was done.
If you check out
https://doc.rust-lang.org/std/iter/trait.Iterator.html
and search for `FnMut`, you see that most of the iterator methods are side-effectful. That is cool and fun and very useful, but it isn't functional programming.
Edit. The term you are probably looking for (guessing) is "higher-order programming":
Re: Functional Language Features in Rust – Iterators and Closures
#25Under 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.
let search = match args.next() {
Some(arg) => arg,
None => return Err("Didn't get a search string"),
};
let search = args.next().ok_or("Didn't get a search string")?;
It might actually be a nice segue into a page on the combinators of Option and Result, since functional-style Rust seems to benefit from liberal use of them.
Re: Functional Language Features in Rust – Iterators and Closures
#26Under 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…
This is a great suggestion! I'm on mobile right now, but I'll file an issue when I get home, or if you feel like it, please do!
Re: Functional Language Features in Rust – Iterators and Closures
#27Earlier 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,…
Yeah that is one way of doing it, but I'm not sure how practically useful it actually is; many functional languages do allow for mutation and/or side effects too. Often in a controlled way, of course, but then again, so does Rust. That said, I wouldn't argue that Rust is a functional language exactly, mostly that I find essentialist FP definitions to be lacking, like most essentialist definitions.
That said, you're right that "higher order" is a better description of these features, but my counter would be that most people perceive higher order programming as an aspect of functional programming, bringing it full circle again :)
Re: Functional Language Features in Rust – Iterators and Closures
#28Earlier quoted context omitted.
> 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,…
Yeah that is one way of doing it, but I'm not sure how practically useful it actually is; many functional languages do allow for mutation and/or side effects too. Often in a controlled way, of course, but then again, so does Rust. That said, I wouldn't argue that Rust is a functional language exactly, mostly that I find essentialist FP definitions to be lacking, like most essentialist definitions. That said, you're r…
Most people perceive structs and fields as an aspect of object-oriented programming, but you probably wouldn't write about them under the heading of "Object-oriented programming".
Maybe change the title to "Functional Language Idioms"?
Re: Functional Language Features in Rust – Iterators and Closures
#29Earlier quoted context omitted.
Yeah that is one way of doing it, but I'm not sure how practically useful it actually is; many functional languages do allow for mutation and/or side effects too. Often in a controlled way, of course, but then again, so does Rust. That said, I wouldn't argue that Rust is a functional language exactly, mostly that I find essentialist FP definitions to be lacking, like most essentialist definitions. That said, you're r…
Most people perceive structs and fields as an aspect of object-oriented programming, but you probably wouldn't write about them under the heading of "Object-oriented programming". Maybe change the title to "Functional Language Idioms"?
The "oh no OOP" chapter is later :)
That's a good suggestion, I'll think about it, thanks :)
Re: Functional Language Features in Rust – Iterators and Closures
#30This is beautiful. Higher order functions and closures are a big reason why I enjoy functional programming languages. To see these applied with method chaining is very exciting in a systems programming language.