3 ms·

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

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.)
    - jolux 6y ago
      That sounds super neat! Haskell always has me jealous of language features, but I’ve committed to focusing on mastering C# and the CLR right now because it’s what I get paid for.
      - eru 6y ago
        See https://www.microsoft.com/en-us/research/wp-content/uploads/2016/08/desugaring-haskell-haskell16.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... and https://simonmar.github.io/bib/papers/haxl-icfp14.pdf https://simonmar.github.io/bib/papers/haxl-icfp14.pdf for more background, if you are interested. It might even contain some ideas you can use in C#.
        Twisol 6y ago
        > It might even contain some ideas you can use in C#. I just implemented the Haxl paper in Java as a weekend project (for implementing GraphQL APIs), so it totally does ;)
        eru 6y ago
        Cool! Have you posted about your experience anywhere?
- Quekid5 6y ago
  What about the Parser monad? Or the Validation Applicative? I think you're being a bit short-sighted here. I fully appreciate that it might be extremely difficult to accommodate these HKTs, etc. in a language with the core values of Rust. That's absolutely fine, because that's probably several research-level projects in and of itself. OTOH, we shouldn't discount the value of such things. It's absolutely fine and reasonable to choose e.g. efficiency over other things, but it's not the only value.

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.)
  - jolux 6y ago
    That sounds super neat! Haskell always has me jealous of language features, but I’ve committed to focusing on mastering C# and the CLR right now because it’s what I get paid for.
    - eru 6y ago
      See https://www.microsoft.com/en-us/research/wp-content/uploads/2016/08/desugaring-haskell-haskell16.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... and https://simonmar.github.io/bib/papers/haxl-icfp14.pdf https://simonmar.github.io/bib/papers/haxl-icfp14.pdf for more background, if you are interested. It might even contain some ideas you can use in C#.
      - Twisol 6y ago
        > It might even contain some ideas you can use in C#. I just implemented the Haxl paper in Java as a weekend project (for implementing GraphQL APIs), so it totally does ;)
        eru 6y ago
        Cool! Have you posted about your experience anywhere?
Quekid5 6y ago
What about the Parser monad? Or the Validation Applicative? I think you're being a bit short-sighted here. I fully appreciate that it might be extremely difficult to accommodate these HKTs, etc. in a language with the core values of Rust. That's absolutely fine, because that's probably several research-level projects in and of itself. OTOH, we shouldn't discount the value of such things. It's absolutely fine and reasonable to choose e.g. efficiency over other things, but it's not the only value.