Async and Await in Rust: a full proposal

Re:Async and Await in Rust: a full proposal by pas on Monday July 16, 2018 @03:10AM (#17539338)

Monads are containers for which .map, and .flatMap (>>= in Haskell) make sense.

Future, Option, List, State/IO, etc.

And the do-notation that some comments mention become a long list of flatMap/filter/map invocations.

  do {
    futRecord <- getDBrecord(username, passw) 
    uid = futRecord.map(record -> record.id)
    username = futRecord.map(record -> record.name)
    futResult <- setUserLastLoggedIn(uid, now())
    futResult <- checkUserACL(uid, operation.roles)
  } yield username

This is just an abstraction, and it's not exactly a pretty one, but better than the flatMap hell in functional languages.

The do-notation uses the same monad throughout, in this example the Future one. The final yield is a map, the "<-" lines all represent a flatMap.

Finally, Monads are very much like Vector Spaces in Maths. You have Axioms for both, and if the object satisfies them, it's a Monad or Vector Space!

https://devth.com/2015/monad-laws-in-scala

https://en.wikipedia.org/wiki/Vector_space#Definition

[ Parent | on HN ]

Re:Async and Await in Rust: a full proposal by forkerenok on Monday July 16, 2018 @03:32AM (#17539413)

I would remove "containers" from the first line. In my reading it is ANYTHING for which monad laws hold.

[ Parent | on HN ]

Re:Async and Await in Rust: a full proposal by Sharlin on Monday July 16, 2018 @06:47AM (#17540213)

For better or worse, "container" is the most intuitive concept to use when trying to explain monads. Yes, there are monad instances that don't really fit the container model, but they're not important at first. Definining "monad" as a thing for which monad laws hold is exactly the sort of almost-tautological non-explanation that makes people roll their eyes at FP aficionados.

However, I agree that the important step in understanding monads as an abstraction is realizing how map and flatmap make sense for many things other than lists.

[ Parent | on HN ]

Re:Async and Await in Rust: a full proposal by sullyj3 on Monday July 16, 2018 @11:32AM (#17542076)

> Definining "monad" as a thing for which monad laws hold is exactly the sort of almost-tautological non-explanation that makes people roll their eyes at FP aficionados.

Thank-you for crystallizing and articulating a frustration I have often, as a beginner to intermediate Haskeller.

[ Parent | on HN ]

Re:Async and Await in Rust: a full proposal by pas on Monday July 16, 2018 @08:36AM (#17540789)

I guess flatMap is very misleading to newcommers. Probably simply calling it chaining, composition, or even "then" would help.

[ Parent | on HN ]

Re:Async and Await in Rust: a full proposal by sullyj3 on Monday July 16, 2018 @11:40AM (#17542158)

I like chaining, that's a good analogy.

I feel like, now that I have a certain level of intuitive understanding of what bind does, to me, the `>>=` symbol best represents what the operation does. It just looks like some kind of physical gadget that extracts a thing from a container, does something to it, and injects it into the next container. This is pretty ironic given Haskell's (somewhat deserved) reputation as impenetrable symbol soup. I don't know whether I'd endorse trying to use an intuitive mnemonic like this to explain monads to FP beginners.

[ Parent | on HN ]

Re:Async and Await in Rust: a full proposal by pas on Tuesday July 17, 2018 @04:50AM (#17548275)

I know a lot of symbols, but I still get irritated when I encounter a new one, and I can't search for it. (At least math got a nice list: https://en.wikipedia.org/wiki/List_of_mathematical_symbols )

For math it's kind of okay. Because there the point is to talk about that theory. You introduce definitions, and theorems, and use them in proofs. Or in calculations.

And even in math proofs usually come with a lot of explanation. (At least the better ones.)

In software engineering maintainability is important.

And, sure, we can just accept that Haskell is something that you can't learn by looking at real world Haskell code. After all, you can't really learn real world "research math" by looking at it.

But I think real world code, especially one that is looking for maintainers should not err on the side of indecipherability and inapproachability.

I continue to chastise Scalaz for its bad naming and documentation convention. (Haskell is ... well, it's irredeemable.)

And TypeScript is getting into this mess too. The documentation for new releases with new type system goodies (and I really mean it, I like powerful type systems, I just don't want to spend my life on understanding them, I'm happy to use them to get particular jobs done), but with barely enough documentation to let serious TS users with many years of experience understand it.

[ Parent | on HN ]

Re:Async and Await in Rust: a full proposal by Sharlin on Monday July 16, 2018 @08:54AM (#17540902)

That's true, although it's better than "bind".

[ Parent | on HN ]

Re:Async and Await in Rust: a full proposal by pas on Monday July 16, 2018 @08:34AM (#17540777)

They have something in them (sometimes just a very fuzzy non-explicit state, maybe a seed for a RNG, but there's something there, otherwise it'd be just a value). Every monad is a [type] constructor, wrapping something.

Or could you show a counterexample please?

[ Parent | on HN ]