Okay, so Monad can't abstract over Future, but still let's have Monad. Problem: we don't have higher kinded polymorphism, and probably never will.
Conversation
The problem is that without currying at the type level, higher kinded polymorphism makes type inference trivially undecidable. We have no currying.
2
5
26
In order to add higher kinded polymorphism, we'd have to restrict the sorts of types you could use in a way that would feel very arbitrary to users.
1
3
17
In contrast, generic associated types don't have this problem, and directly solve the expressiveness problems we do have, like Iterable (abstracting over everything with a `.iter(&self)` method)
1
4
26
(Don't get me wrong, you can write something to abstract over some monads like Option and Result using generic associated types. But its much less ergonomic than Monad in Haskell, even for those).
1
4
23
IN CONCLUSION: a design that works in a pure FP which lazily evaluates and boxes everything by default doesn't necessarily work in an eager imperative language with no runtime.
4
24
118
At this point I think it’s too late to add an effect system to Rust, but algebraic effects could work—that’s the approach I’m taking in my eager runtimeless language. They’re useful for tagging effects even if you don’t have fully general “handlers” (requiring continuations).
1
2
Yes an effect system is possible because - like async/await - it builds the suspension points into the language
1
2
The problem then has always been motivating the generalization
2
Agreed—I guess what I was getting at was that it’s invasive & compatibility-breaking to retrofit a language & standard library with effects everywhere. It’s the kind of thing that ideally ought to be done from the beginning, paying the cost incrementally rather than all at once.
1
2
Yeah, this is my feeling - there were proposals for effects pre-1.0, but there was less understanding of the performance costs that we have now. I think OCaml has a decent shot at it, but there are different things at play.