There's an important concept in Haskell called Higher-kinded Kinded polymorphism, which is at the moment missing in Rust. Unfortunately, without this you can't really express the essence of these concepts.
The functor itself should be polymorphic on type which is itself polymorphic, e.g.: Functor<F<A>>
In here the F is our higher-kinded type polymorphic on another type A (btw, in Haskell a type of types is called kind).
And then your functor definition would look more like this (this is not valid Rust code):
In here we're applying a function A -> B over a F<A> to get back a F<B>.
And then the instance for Option would look more like this:
impl Functor<Option<A>> for Option<A> {
fn fmap(self, func: fn(A) -> B) -> Option<B> {
self.map(func)
}
}
Here, the Option steps in as a concrete implementation of F from the definition of Functor above, while A stays polymorphic. So we're applying a function A -> B over an Option<A> to get back an Option<B>.
also I kinda miss manipulating list/string like I did in clojure in Rust too lol, but in Rust the preferred way seem to be doing everything in place, rather than returning a new list/string whenever mutation happens.
I know, I only implement it for i32 because I wanted to get a feeling of what they are (Functor, Applicatives, Monad), not trying to implement them in Rust actually (hence this is a cheat as it is not a full implementation).
Also I am still learning Rust (which is surprisingly hard when it comes to ownership, liftimes etc.) and is still struggling lol. Am currently going through the Rust-101 tutorial. I previously picked up a language through a random list of coding puzzles/katas (for example 4clojure when I was learning clojure), but i don't really learn much about the language completing those problems, so preferred something more structured. Rust-101 is close, but am still looking for something better.
Hey,
There's an important concept in Haskell called Higher-kinded Kinded polymorphism, which is at the moment missing in Rust. Unfortunately, without this you can't really express the essence of these concepts.
The functor itself should be polymorphic on type which is itself polymorphic, e.g.:
Functor<F<A>>
In here the
F
is our higher-kinded type polymorphic on another typeA
(btw, in Haskell a type of types is called kind).And then your functor definition would look more like this (this is not valid Rust code):
In here we're applying a function
A -> B
over aF<A>
to get back aF<B>
.And then the instance for Option would look more like this:
Here, the
Option
steps in as a concrete implementation ofF
from the definition ofFunctor
above, whileA
stays polymorphic. So we're applying a functionA -> B
over anOption<A>
to get back anOption<B>
.also I kinda miss manipulating list/string like I did in clojure in Rust too lol, but in Rust the preferred way seem to be doing everything in place, rather than returning a new list/string whenever mutation happens.
I know, I only implement it for i32 because I wanted to get a feeling of what they are (Functor, Applicatives, Monad), not trying to implement them in Rust actually (hence this is a cheat as it is not a full implementation).
Also I am still learning Rust (which is surprisingly hard when it comes to ownership, liftimes etc.) and is still struggling lol. Am currently going through the Rust-101 tutorial. I previously picked up a language through a random list of coding puzzles/katas (for example 4clojure when I was learning clojure), but i don't really learn much about the language completing those problems, so preferred something more structured. Rust-101 is close, but am still looking for something better.
I see. It’s been a while since touched Rust, so I can’t comment much on it, but you might like the immutable collections crate immutable.rs/