5 ms·

> Option and Result are Monads. Surely he misses do-notation. You can find monads everywhere if you look hard enough. But Haskell actually lets you use those d

by creata 6y ago

> Option and Result are Monads. Surely he misses do-notation. You can find monads everywhere if you look hard enough. But Haskell actually lets you use those discoveries for massive code reuse, while Rust forces you to write stuff like Result::and_then and Result::map over and over again. > To say that Rust is a child of Haskell is really overstating the case. Right, most of these are common influences. I'd say Rust's main contributions are (a) the ownership system, and (b) painting a thin coat of C++ syntax over ML features to make them more palatable, and neither of these seem all that inspired by Haskell.

fnord123 6y ago
>Rust forces you to write stuff like Result::and_then and Result::map over and over again. The feature of Haskell that lets you avoid writing 'and_then" over and over is do-notation.
- 59nadir 6y ago
  What everyone is talking about isn't "not having to write `and_then` over and over" but rather that there is a common interface to "things that are monads", i.e. `>>=`, `map` and `apply`. `do`-notation is nice syntactic sugar on top of that common interface, but it's not the actual thing itself.
- choeger 6y ago
  It is not. do notation is just syntactic sugar. The feature that enables re-use are the type-classes and the structure of the standard library. Interestingly, you do have traits in rust, but I think there is no monad trait yet in the std lib.
  - steveklabnik 6y ago
    There is not a monad trait because we do not have higher kinded types, which is a requirement. Beyond that, it's not clear that a monad trait would work, even if we did. It may, but it also may not. We'll see (or not) I guess.
    - bad_user 6y ago
      Why wouldn't a Monad trait work? You mean you couldn't express it in Rust, even with HKTs? Or you mean that it wouldn't be useful?
      - steveklabnik 6y ago
        Both. See here for more https://twitter.com/withoutboats/status/1027702538563477505 https://twitter.com/withoutboats/status/1027702538563477505 There have been some people working on these problems, take https://varkor.github.io/blog/2018/11/10/monadic-do-notation-in-rust-part-i.html https://varkor.github.io/blog/2018/11/10/monadic-do-notation... for example. This is why I say "not clear" and not "impossible" or something. We just don't know.
      - deleted 6y ago
        [deleted]
      - Quekid5 6y ago
        It's basically a research-level problem given the other constraints of Rust. (Which is fine. Trade-offs and all that.)
- creata 6y ago
  I think you misunderstand. I mean that merely by implementing the Monad typeclass, you get a ton of methods (mapM_, join, etc.) for free. You can't do that in Rust right now.
  - fnord123 6y ago
    I wonder if these could be written against the Carrier trait.
Ar-Curunir 6y ago
You can totally use macros to reimplement do notation in rust, and that's what many crates on crates.io already do.
- Quekid5 6y ago
  Do notation isn't the important part. It's the reuse you get from the Monad, Applicative, Functor, etc. traits/typeclasses. (Of course you still want some form of nicer notation than the raw one, but that's beside the point.)
  - Ar-Curunir 6y ago
    Rust obviates the need for many uses of these monads, either by not requiring purity (so no IO monad), or by enabling controlled mutability (so no State monad). Out of the remaining monads that are in common use (Result, Option, Future), it doesn't seem particularly worthwhile to try cram them all into the same API, when you could instead try to design better specialized APIs (as has been done with Future)
    - jolux 6y ago
      The monadic interface is not the only API surface those types have in Haskell. It very rarely is. There’s no “cramming,” they either have monadic structure or they don’t, and if they do it’s very convenient to be able to treat them as monads.
      - eru 6y ago
        Just to be pedantic, we also recently got applicative-do. So you can use a subset of do-notation for the much more prevalent Applicative Functors, too. In practice applicative functors are even more prevalent than their subset, monads. If you can express your algorithm using the weaker applicative combinators only, there's more opportunity for optimisation and parallelism. (And the code is easier to understand for your readers, because there are fewer interactions for them to worry about, too.)
skybrian 6y ago
I guess you could call shorter ways to write and_then or map code reuse, but it's at such a small scale that it seems more like terseness? Little abbreviations might be widely used, but when people talk about code reuse I'm hoping to hear about ways to share larger chunks of code, not having shorter idioms.
- creata 6y ago
  I think I've worded things very poorly. In Rust, the functions Result::and_then, Result::map, Option::and_then, Option::map, etc. are pretty much all saying the exact same thing, but they need to be reimplemented over and over again. With Haskell, Result and Option (and [], QuickCheck.Gen, Data.Binary.Get, etc.) just need to implement return and (>>=), and they get a ridiculous amount of useful functions for free (mapM_, foldM_, forever, ap, etc.). That's a "large chunk of code" saved in my opinion. https://hackage.haskell.org/package/base-4.14.0.0/docs/Control-Monad.html https://hackage.haskell.org/package/base-4.14.0.0/docs/Contr... And, of course, they also get some very nice sugar in the form of do notation.
  - eru 6y ago
    Completely agreed. In addition: Having popular interfaces like monad, applicative functors, monoids etc also suggests common ways to structure any API you are working on. If you design an API from scratch and have to implement everything again and again, you might be tempted into a pretty arbitrary breakdown of the problem space. Whereas in Haskell personal laziness drives you to look hard to see if you can express your API in terms of foldable and traversable or monads etc so that you get lots of functions for free. Those common interfaces also automatically suggest gaps in your API that otherwise you would have only noticed after using your API for a while (or by being a very experienced programmer).

by creata 6y ago

fnord123 6y ago

>Rust forces you to write stuff like Result::and_then and Result::map over and over again. The feature of Haskell that lets you avoid writing 'and_then" over and over is do-notation.

59nadir 6y ago
What everyone is talking about isn't "not having to write `and_then` over and over" but rather that there is a common interface to "things that are monads", i.e. `>>=`, `map` and `apply`. `do`-notation is nice syntactic sugar on top of that common interface, but it's not the actual thing itself.
choeger 6y ago
It is not. do notation is just syntactic sugar. The feature that enables re-use are the type-classes and the structure of the standard library. Interestingly, you do have traits in rust, but I think there is no monad trait yet in the std lib.
- steveklabnik 6y ago
  There is not a monad trait because we do not have higher kinded types, which is a requirement. Beyond that, it's not clear that a monad trait would work, even if we did. It may, but it also may not. We'll see (or not) I guess.
  - bad_user 6y ago
    Why wouldn't a Monad trait work? You mean you couldn't express it in Rust, even with HKTs? Or you mean that it wouldn't be useful?
    - steveklabnik 6y ago
      Both. See here for more https://twitter.com/withoutboats/status/1027702538563477505 https://twitter.com/withoutboats/status/1027702538563477505 There have been some people working on these problems, take https://varkor.github.io/blog/2018/11/10/monadic-do-notation-in-rust-part-i.html https://varkor.github.io/blog/2018/11/10/monadic-do-notation... for example. This is why I say "not clear" and not "impossible" or something. We just don't know.
    - deleted 6y ago
      [deleted]
    - Quekid5 6y ago
      It's basically a research-level problem given the other constraints of Rust. (Which is fine. Trade-offs and all that.)
creata 6y ago
I think you misunderstand. I mean that merely by implementing the Monad typeclass, you get a ton of methods (mapM_, join, etc.) for free. You can't do that in Rust right now.
- fnord123 6y ago
  I wonder if these could be written against the Carrier trait.

Ar-Curunir 6y ago

You can totally use macros to reimplement do notation in rust, and that's what many crates on crates.io already do.

Quekid5 6y ago
Do notation isn't the important part. It's the reuse you get from the Monad, Applicative, Functor, etc. traits/typeclasses. (Of course you still want some form of nicer notation than the raw one, but that's beside the point.)
- Ar-Curunir 6y ago
  Rust obviates the need for many uses of these monads, either by not requiring purity (so no IO monad), or by enabling controlled mutability (so no State monad). Out of the remaining monads that are in common use (Result, Option, Future), it doesn't seem particularly worthwhile to try cram them all into the same API, when you could instead try to design better specialized APIs (as has been done with Future)
  - jolux 6y ago
    The monadic interface is not the only API surface those types have in Haskell. It very rarely is. There’s no “cramming,” they either have monadic structure or they don’t, and if they do it’s very convenient to be able to treat them as monads.
    - eru 6y ago
      Just to be pedantic, we also recently got applicative-do. So you can use a subset of do-notation for the much more prevalent Applicative Functors, too. In practice applicative functors are even more prevalent than their subset, monads. If you can express your algorithm using the weaker applicative combinators only, there's more opportunity for optimisation and parallelism. (And the code is easier to understand for your readers, because there are fewer interactions for them to worry about, too.)

skybrian 6y ago

I guess you could call shorter ways to write and_then or map code reuse, but it's at such a small scale that it seems more like terseness? Little abbreviations might be widely used, but when people talk about code reuse I'm hoping to hear about ways to share larger chunks of code, not having shorter idioms.

creata 6y ago
I think I've worded things very poorly. In Rust, the functions Result::and_then, Result::map, Option::and_then, Option::map, etc. are pretty much all saying the exact same thing, but they need to be reimplemented over and over again. With Haskell, Result and Option (and [], QuickCheck.Gen, Data.Binary.Get, etc.) just need to implement return and (>>=), and they get a ridiculous amount of useful functions for free (mapM_, foldM_, forever, ap, etc.). That's a "large chunk of code" saved in my opinion. https://hackage.haskell.org/package/base-4.14.0.0/docs/Control-Monad.html https://hackage.haskell.org/package/base-4.14.0.0/docs/Contr... And, of course, they also get some very nice sugar in the form of do notation.
- eru 6y ago
  Completely agreed. In addition: Having popular interfaces like monad, applicative functors, monoids etc also suggests common ways to structure any API you are working on. If you design an API from scratch and have to implement everything again and again, you might be tempted into a pretty arbitrary breakdown of the problem space. Whereas in Haskell personal laziness drives you to look hard to see if you can express your API in terms of foldable and traversable or monads etc so that you get lots of functions for free. Those common interfaces also automatically suggest gaps in your API that otherwise you would have only noticed after using your API for a while (or by being a very experienced programmer).