undefined | Better HN

0 pointstreyd2y ago0 comments

Rust's error handling and option types actually aren't monads, they just have similar ergonomics for end users. There's some tricks that have to be done to make them work in a eager evaluation context, and as a result implementing iterator combinators does not feel like working with modads.

0 comments

mkehrt2y ago

In what sense aren't they monads? They have a bind method ("and_then") and a return method (Which is just the variant for constructing the success case, i.e. "Ok" or "Some"). It's more idiomatic to use "map", but that's just a degenerate case of bind.

> There's some tricks that have to be done to make them work in a eager evaluation context...

Monads have nothing to do with laziness, though. In Haskell, IO actions are used with laziness and to work around purity, and IO actions form a monad. But that's just one instance of monad.

treydOP2y ago

After doing some research to refresh my memory I found this old thread: https://users.rust-lang.org/t/what-is-a-monad-and-who-needs-...

I believe what I had originally told that makes them not monads is that because Rust goes through some convlutions to fake the laziness of Haskell monads, it makes them not be typed like Haskell monads.

For example, the declaration of the `.flat_map` on an iterator is actually `fn flat_map<U, F>(self, f: F) -> FlatMap<Self, U, F> where Self: Sized, U: IntoIterator, F: FnMut(Self::Item) -> U`, which uses a "do-er" struct instance of `FlatMap` and is itself another iterator. Evaluating the entire monad-ish iterator combinator chain with something like `.collect()` or `.last()` or something is what triggers the evaluation.

yw34102y ago

Monads have nothing to do with laziness and we're talking about the Result type anyway.

OP is correct. If it has a bind, pure and map (which it does!) then for all intents it forms a monad.

Now the fact is you can't _manipulate_ monads in Rust easily (see kinds and discussions wrt GAT), but nonetheless monads are present in all languages with ADTs in the same way that rings are present in all languages with addition.

kaba02y ago

A Monad is just something to which certain properties apply. An easier example to grasp is a Monoid, which is anything that has an associative binary operator, and an identity element. E.g. nonnegative integers’ addition with 0 is such. Or any list with a concat operation, and the empty list.

So even in weaker languages you get monads the difference is that you can’t abstract over them. Your Haskell code can take a Monad, and work with those, most other languages (I believe Rust included) can’t handle them uniformly all over the language. But they can have types that are mathematically speaking monads.

mkehrt2y ago

Ah interesting. I think it's close enough as to make no difference, but I see what you're saying.

j / k navigate · click thread line to collapse

0 comments

mkehrt2y ago

> There's some tricks that have to be done to make them work in a eager evaluation context...

Monads have nothing to do with laziness, though. In Haskell, IO actions are used with laziness and to work around purity, and IO actions form a monad. But that's just one instance of monad.

treydOP2y ago

After doing some research to refresh my memory I found this old thread: https://users.rust-lang.org/t/what-is-a-monad-and-who-needs-...

yw34102y ago

Monads have nothing to do with laziness and we're talking about the Result type anyway.

OP is correct. If it has a bind, pure and map (which it does!) then for all intents it forms a monad.

kaba02y ago

mkehrt2y ago

Ah interesting. I think it's close enough as to make no difference, but I see what you're saying.

j / k navigate · click thread line to collapse