4 ms·
Fold isn't an operation on a specific monad, it's a generic operation over any monad. Adding it to Option defeat the whole point of thinking about Option as a m
by geofft 7y ago
Fold isn't an operation on a specific monad, it's a generic operation over any monad. Adding it to Option defeat the whole point of thinking about Option as a monad, i.e., the ability to apply generic algorithms that work on any type constructor that follows the monad laws.
(If the question is why no generic fold over any monad exists in Rust, the short answer is that Rust isn't Haskell. Which is great, it means Rust can specialize in things Haskell can't and vice versa. Personally my favorite example is that Haskell avoids shared mutable state by avoiding mutable state, and Rust avoids shared mutable state by avoiding shared mutability. Both have their downsides but each works better for different applications.)
- smabie 7y agoSure, but Scala supports monads via the 'for' construction and yet, no monad trait or class is defined in the base language at all. Even if they are defined ad-hoc on each type, there's value there.
- lmm 7y ago> Fold isn't an operation on a specific monad, it's a generic operation over any monad. Adding it to Option defeat the whole point of thinking about Option as a monad, i.e., the ability to apply generic algorithms that work on any type constructor that follows the monad laws. Having the same function exist with the same name helps communicate with other programmers, even if you can't express the fact that it's actually the same function at the language level. Just like in a language without generics you might still have add(int, int), add(decimal, decimal), add(string, string) and add<T>(list<T>, list<T>) functions. Rust already offers a function called "and_then" on most of its monadic types, and a programmer can see and understand that these are all in some sense "the same function" even though there's no way to abstract over that.
- foldr 7y agoBut 'fold' isn't very useful over option types as there aren't really any non-trivial operations that you can perform on something that's either Nothing or Just x. I think OP was probably thinking of folding over a list of option types, which you can do easily enough in Rust.
- lmm 7y agoThat's the opposite of my experience; fold is probably the main way I consume options in Scala. It's pretty much the only thing you ultimately want to do with an option, after you've finished transforming and composing.
- foldr 7y agoI'm really puzzled by this. Which Haskell 'fold' function would I ever want to apply to a Maybe type? I think there must be some kind of terminological variation in the use of 'fold' here. edit: Ah yes, I see that Scala chooses to use the name 'fold' for what is essentially the 'maybe' function in Haskell. I don't think there is any very useful generic notion of 'fold' that corresponds to this usage. (I see how the operation is a kind of fold, but the type signature of the function isn't flexible enough to be used for any foldable type.) So that is why Rust and Haskell don't name this operation 'fold'.
- shirogane86x 7y agoActually, in Haskell, given that Maybe is Foldable, you can technically implement the maybe function as maybe' def f value = foldr (const . f) def value Although in pratcice almost noone uses Maybe's foldable instance (and it also doesn't scale to other datatypes, like Either, nearly as well, because of the multiple type parameters).
- lmm 7y agoAh, indeed. That said I do occasionally use foldLeft, foldMap, and sum (which I think is what Haskell calls fold?) on options, so I'd say there are a handful of legitimate use cases for most kinds of folds.
- geofft 7y agoAnd here we see exactly why implementing a specific function on a specific instance of a monad isn't the answer - two users of two different, well-respected functional languages can't communicate.