Functors and Monads for People Who Have Read Too Many “Tutorials”

Re:Functors and Monads for People Who Have Read Too Many “Tu... by lmm on Saturday June 26, 2021 @02:25AM (#27639634)

Monads are a very effective technique for expressing custom requirements in your type system, e.g. "this function must be called only in a database transaction", "this function writes an audit log entry", "this function requires this level of authorization". The kind of thing you might think you would have to do via AOP/decorators/monkeypatching, you can usually do in plain old code (with all the attendant advantages) via a monad.

If your type system can't express them then you lose most of the advantages and they're pretty pointless.

[ Parent | on HN ]

Re:Functors and Monads for People Who Have Read Too Many “Tu... by calo_star on Saturday June 26, 2021 @04:35AM (#27640212)

I find this perspective intriguing, can you elaborate on that? For example why `m a -> (a -> m b) -> m b` but not something else?

[ Parent | on HN ]

Re:Functors and Monads for People Who Have Read Too Many “Tu... by uryga on Saturday June 26, 2021 @09:32AM (#27641653)

> why `m a -> (a -> m b) -> m b` but not something else?

it's basically continuation-passing-style (`a -> m b` is the "continuation"), you might as well ask "why can you represent so many control-flow things using CPS?". idk why, but you can!

from another angle, you could compare Monad with the less powerful Applicative. a formulation[0] that's easier to parse than the usual one[1] is:

  class Functor f => Applicative f where
    unit :: f ()
    pair :: f a -> f b -> f (a, b)

if you're familiar with JS Promises, a rough analogy would be

  >>=  (Monad)        Promise.then
  pair (Applicative) ≈ Promise.all
  unit   (Applicative) =
  return (Monad)       = Promise.resolve

ignoring parallelism, you can implement Promise.all using Promise.then, but not the other way around.

---

[0] Called "Monoidal" here: https://stackoverflow.com/q/45267953 [1] https://en.m.wikibooks.org/wiki/Haskell/Applicative_functors...

[ Parent | on HN ]

Re:Functors and Monads for People Who Have Read Too Many “Tu... by lmm on Saturday June 26, 2021 @06:07AM (#27640642)

Some people describe monads as "programmable semicolons" - they're pretty much the general concept of sequencing, "do this then do that", or indeed of imperative code. I don't think they're necessarily the ideal abstraction - something like ArrowChoice is "better" in a lot of cases - but in practice they seem to come up a hell of a lot, you can represent almost anything as a monad.

[ Parent | on HN ]

Re:Functors and Monads for People Who Have Read Too Many “Tu... by wyager on Saturday June 26, 2021 @09:16AM (#27641555)

Why monads and not something else? Because monads appear to be a/the mathematical structure underlying the denotation of programs with effects.

Why that type signature? You only have two options: that, or m (m a) -> m a. The former is more popular for ergonomic reasons mostly. It doesn’t really matter.

[ Parent | on HN ]

Re:Functors and Monads for People Who Have Read Too Many “Tu... by rocqua on Saturday June 26, 2021 @09:36AM (#27641684)

Because so many types above are m of something. You as a programmer get to decide how that m type works, so you have a lot of control there.

[ Parent | on HN ]