4 ms·

The "?" operator looks like a more specialized, error/success-specific version of monads. Has there been any discussion about generalizing everything into monad

The "?" operator looks like a more specialized, error/success-specific version of monads. Has there been any discussion about generalizing everything into monad-style chaining operators? I see that there is some discussion here [1], including a suggestion to add a Haskell-style "do" block. But that's just one guy's blog post. [1] https://m4rw3r.github.io/rust-questionmark-operator https://m4rw3r.github.io/rust-questionmark-operator.

steveklabnik 10y ago
Yes, that was endlessly discussed as part of all of this. The TL;DR is: it's not simple. ? is very straightforward and helps people out a lot today. So if and when (and it is a big if) Rust ever gets do notation, this might be a little redundant, but blocking one of people's largest pain points today is worth the (possible) little bit of redundancy.
- lobster_johnson 10y ago
  Thanks, that makes perfect sense. I haven't followed the internal discussion at all. It sounds like there are some that would like to move Rust in the direction of becoming more Haskell/ML-like (which is to say more purely functional) rather than the current balance between imperative and functional? Is there any internal tension in that regard?
  - steveklabnik 10y ago
    It's not even a philosophical difference, really, there are technical objections that would have to be addressed somehow before it would even be possible, let alone figure out if it's a feature that's desired. These involve things like "it's still unclear if HKT is going to end up in Rust or not, and how", which is a pre-requirement, as just one example.
  - mathw 10y ago
    I believe one of the biggest obstacles to a general monad system in Rust is that the type system can't actually handle it at the moment - it requires higher-kinded types, which may or may not ever actually be added to the language.
    - GolDDranks 10y ago
      There's another problem too: a monad trait would unify types behind a monadic interface, but many things that in Haskell are types, are traits in Rust. This is because Rust requires a single type to have uniform memory representation and to be statically dispatchable (save for trait objects). So in Rust, there is not just an "iterator type", but multiple types that have the Iterator trait. The same goes for Future trait. This leads to a situation where, if there were to be a monad trait, that trait should abstract over not only types, but another traits generically. Not to speak about some other hurdles, like lifetimes. The design space is inherently more convoluted than in languages with boxed, possibly dynamically dispatched types. It may be possible, but it's not easy, and we can't copy the monads straightforwardly from Haskell or Scala.
      - mathw 10y ago
        Good point! A whole other set of things also need to be hoisted to make this work.
tatterdemalion 10y ago
The semantics of ? are different from monadic bind and fit better to Rust's language context of strictness, imperativeness, and mutability than Monad (which is a problematic type class in Rust for some separate reasons).

steveklabnik 10y ago

Yes, that was endlessly discussed as part of all of this. The TL;DR is: it's not simple. ? is very straightforward and helps people out a lot today. So if and when (and it is a big if) Rust ever gets do notation, this might be a little redundant, but blocking one of people's largest pain points today is worth the (possible) little bit of redundancy.

lobster_johnson 10y ago
Thanks, that makes perfect sense. I haven't followed the internal discussion at all. It sounds like there are some that would like to move Rust in the direction of becoming more Haskell/ML-like (which is to say more purely functional) rather than the current balance between imperative and functional? Is there any internal tension in that regard?
- steveklabnik 10y ago
  It's not even a philosophical difference, really, there are technical objections that would have to be addressed somehow before it would even be possible, let alone figure out if it's a feature that's desired. These involve things like "it's still unclear if HKT is going to end up in Rust or not, and how", which is a pre-requirement, as just one example.
- mathw 10y ago
  I believe one of the biggest obstacles to a general monad system in Rust is that the type system can't actually handle it at the moment - it requires higher-kinded types, which may or may not ever actually be added to the language.
  - GolDDranks 10y ago
    There's another problem too: a monad trait would unify types behind a monadic interface, but many things that in Haskell are types, are traits in Rust. This is because Rust requires a single type to have uniform memory representation and to be statically dispatchable (save for trait objects). So in Rust, there is not just an "iterator type", but multiple types that have the Iterator trait. The same goes for Future trait. This leads to a situation where, if there were to be a monad trait, that trait should abstract over not only types, but another traits generically. Not to speak about some other hurdles, like lifetimes. The design space is inherently more convoluted than in languages with boxed, possibly dynamically dispatched types. It may be possible, but it's not easy, and we can't copy the monads straightforwardly from Haskell or Scala.
    - mathw 10y ago
      Good point! A whole other set of things also need to be hoisted to make this work.

tatterdemalion 10y ago

The semantics of ? are different from monadic bind and fit better to Rust's language context of strictness, imperativeness, and mutability than Monad (which is a problematic type class in Rust for some separate reasons).