Inventing Monads

by stopachka • 6 years ago

128 119 6 years ago

tarkin2• 6 years ago

[Edited away]

As someone who isn't familiar with functional programming, what benefit does this give us over throwing an error when trying to access a resource that doesn't exist?

raiflip5• 6 years ago

What if you need to access 5 resources in a row, any of which can throw exceptions? A monad centralizes the repeated logic in its flatMap function.

edflsafoiewq3• 6 years ago

I think the comparison is to something like this

  try:
    user = getUser()
    profile = getProfile(user)
    pic = getProfilePicture(profile)
    thumb = getThumbnail(pic)
    return thumb

  except Missing:
    return None

TheMatten• 6 years ago

Well, nothing stops you from implementing equivalent wrapper using error mechanics (that could actually make it faster in some cases), but turning this idea into first-class value allows you to abstract over it easily. E.g. in Haskell, base library comes with lots of functions for manipulating monadic wrappers in generic ways, mapping, sequencing and threading through them in common way (once you start using them, you actually realise that a lot of business logic that looks perfectly reasonable in common languages ends up being boilerplate that can be avoided easily using simple combinator).

Few of them are actually bound to syntactic sugar known as "do-notation", that let's you write that sequenced code in post as if you were binding simple variables, adding branching, effectful statements or auxiliary definitions along the way. This really pays out when you start turning simple monads into so-called "monad transformers", that let you stack multiple behaviours/wrappers on top of each other, keeping the same pretty do-notation untouched.

jlg23• 6 years ago

WRT this specific post: Graceful error propagation with zero boilerplate code for passing through errors. If all you need to know is "nope" at the end of some computation, you won't have to handle all different "nopes" you encounter en route. Or the other way round: You can write lots of code without checking input values (for null, in this case) because you have a guarantee it won't be called if the input value is invalid (null here).

EDIT: I have serious problems with the post, because a) it claims that discovering one application of monads is understanding monads, b) for me the true strength of monads shines in strictly typed languages, everything else is just an approximation of the concept.

marcosdumay2• 6 years ago

One is just plain code that you write on a library. The other is a special construction on the compiler that will solve this specific use case. Your question is on the wrong way around. You should be asking why do you need specialized compiler support for just that use case.

Notice that that short introductory article already has examples of two different monads. People use many more of them.

jmull• 6 years ago

It’s not good if each library/component/framework or other unit of independently developed code uses a different error handling scheme.

So the ability to define this independently isn’t useful. You want to create a standard. Whether that goes into the standard library, or gets a little language syntax support as well, is something you can argue about, but is pretty arbitrary and probably just comes down to the style of the language.

The burden on the developer is equal: the hard part is learning the conceptual patterns, how to compose solutions in terms of them, and how other libraries you use expect you to use them.

Scandiravian3• 6 years ago

Throwing an error is implicitly making a decision, that there's no way to recover to a working state for the program

A lot of times that's a perfectly fine decision, but six months down the road when the code has grown a lot, you might find an alternative way to get the resource on a fail

If you made a decision to throw an exception immediately after failing to get the resource, you then have to either rewrite the logic, which can be very expensive, or catch the error, which bloats the code (throwing the exception is now redundant and is fixed by adding code that catches that exception)

By instead putting the return value in an appropriate monad, you can postpone throwing the exception until you're sure that there's no way to recover

Throwing an exception is still something that's necessary occasionally, but it should not be done until there's no possible way to recover, and be done in a way, so it's easy to rewrite if a way to recover becomes available at some future point in time

ianhorn3• 6 years ago

A monad's special function application lets you write much simpler code in certain situations.

Say you're working with some data structure that contains/emits numbers: a pointer to a resource containing a number. A list of numbers. A function that returns a number. An optional number (or null).

A common operation is unpacking that structure to get a number, applying a function to the number, and packing it back up: Reading from the pointer, applying the function, and returning a pointer of the result. Applying the function to each element of the list and returning a list of the results. Composing a function with another function. Applying a function to the optional number or just returning the null.

When you're writing code on this, it's error prone to do the unpacking, application, and repacking. It's much simpler if you can write code that looks like `def f(x): return exp(x)/x + 23`. Much more testable too. If you have two or more of these structured things, it might get even more error prone. It's much easier to write code that takes three integers and does stuff, instead of writing code that takes three pointers/lists/functions/optionals.

Monads are part of a hierarchy that abstracts that. Anything that defines that sort of function application in a particularly convenient way is a monad. There's more to it, but that's why it's useful.

It lets you write code dealing with the things in your data structure, letting you mostly ignore the structure itself.

-------

In this specific situation, say you want to replace your error handling with something else. Maybe it writes to a log file then errors. Or maybe it does something fancier. Or maybe you even change the way you get the resource as well as the erroring to something fancy. As you swap out the "structure" code, with a monad it's just switching to a new monad, rather than refactoring the business logic related code. It's a nice separation of concerns.

Izkata3• 6 years ago

Anything that defines that sort of function application in a particularly convenient way is a monad. There's more to it, but that's why it's useful.

Aaand with this statement you skipped over what IMO is the most important missing piece, because everything above it fits higher-order functions such as map(), which as far as I understand aren't monads.

lmm• 6 years ago

You need a special language feature to "throw an error", which can break your reasoning about code. A seemingly harmless refactor like swapping two lines might completely change your behaviour because one of those lines actually threw an error. It becomes very difficult to do things like manage a resource properly (ensuring it's always released), to the point that you probably end up adding more special language features to handle that.

contravariant• 6 years ago

It's the structure you need to be able to throw errors.

chombier2• 6 years ago

This is one example of a monad, probably not the most compelling if your language supports exceptions already (apart from having more explicit types).

But there are many other examples that are useful in practice (IO, streams, parsers, lists, operations in context, futures, etc as mentioned in other threads). A monad is the interface you need to implement for each of these to compose nicely.

Then one day you'll need to compose Foo's, so you'll ask yourself "is there a monad for Foo's?" and if there is the code generally writes itself.

raiflip5• 6 years ago

I really like how this article builds up from a simple real life use case.

Shameless plug for my own article that did something similar about a week ago: https://medium.com/@ameltzer91/an-easy-to-understand-monad-g...

jjjbokma• 6 years ago

Nice article, I linked to it from my tumblelog https://plurrrr.com/archive/2020/08/19.html 10 days ago. Thanks for writing this.

stopachka4• 6 years ago

Thank you for the kind words, and nice article! : )

ratww2• 6 years ago

Good article! I enjoyed that you used flatMap. And the FinancialRegulatorMonad is a great way to show that monads are not just IO, State or Maybe. :)

Kaze404• 6 years ago

Thank you for the article. I had an idea of what Monads were and even played with them a bit in Rust, but I didn't know they had applications more specific than Result/Option types.

cjfd• 6 years ago

In various places on the web one can find the quote that 'Dependency injection is a 25-dollar term for a 5-cent concept'.

I feel it is the same with monads including all the false suggestions that one might need to understand category theory and similar such nonsense.

edflsafoiewq3• 6 years ago

If only DI had a clear definition like "monad" does, I might be able to understand what it is.

stopachka4• 6 years ago

Imagine a function, that accepts another function as an argument.

Badabing badaboom, the essence of dependency injection

goto115• 6 years ago

It just means passing a dependency as an argument to method or constructor. Seriously, it is just that!

chongli2• 6 years ago

suggestions that one might need to understand category theory and similar such nonsense

It’s definitely unnecessary to understand category theory to work with monads. What is helpful, however, is having some comfort with math.

What does that mean exactly? It’s a level of comfort in working with definitions, properties, operations, special elements, proofs. People can get so frustrated because they think they don’t understand what a monad is. Like they want to hold it in their hand the way they would an apple or a tennis ball.

When you’re comfortable with math you kind of lose that need to think about an object concretely. You start to only care about the definitions, properties, axioms, laws, theorems, etc that concern a particular object. Then you just play around with a few examples and see the implications of these things. That’s all there is to it. The power comes from the abstraction. It can take time to become comfortable with abstract concepts though.

Koshkin3• 6 years ago

Another thing that is often missed is that we think we “understand” something when in fact we just got used to it. Even such simple concept as “number” would probably be very difficult to explain to someone (who either doesn’t know what a number is or wishes to “really understand” it).

chowells3• 6 years ago

There's also the classic http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...

Written by a 3-time Oscar winner, no less!

dang• 6 years ago

Looks like there has been only one small discussion from 2009: https://news.ycombinator.com/item?id=958789

guerrilla• 6 years ago

Writen by 3-time Oscar winner, no less!

Sorry, what? Their About page is blank.

dllthomas4• 6 years ago

The author is Dan Piponi: https://pwlconf.org/2018/dan-piponi/

https://www.imdb.com/name/nm0685004/

ridiculous_fish3• 6 years ago

This begins to get us to the fundamental abstraction of a monad: a box, with an interface for map, and flatMap

Before I understood monads, I read variations of the above sentence a million times, always got stuck here: https://i.imgur.com/McThkuh.png

How does this abstraction let us perform IO, do in-place destructive updates, etc? The answer is that it doesn't. These must be primitives supplied by the runtime. A monad like IO has its two functions (return+bind), and a bunch of other magic functions. It's obvious now but that fact is hardly ever stated.

I wonder if anyone has tried explaining from the other direction? Rather than building up to Maybe, try building down from a desire to print Hello World.

chowells3• 6 years ago

I think most of this happens because lots of people say things like "the IO monad" when they actually just mean "IO". It misleads people into thinking the monad part is important. It isn't. IO is the tough concept. Monad is almost trivial.

ridiculous_fish3• 6 years ago

Good point, I agree. But you must learn it to get anything done. Grappling with IO + monad + do-notation all at once is hard!

I once spent a day thinking I had misunderstood something fundamental, but really I just had an errant tab instead of a space.

raiflip5• 6 years ago

A monad really is just a wrapper around a value, with flatMap and return.

For some kinds of monads, like maybe, that’s all you need.

But, some other kinds of monads need more logic. List is one, IO is another.

In OOP language, sometimes all you need is the parent class. But sometimes you need to extend the parent and add more.

ratww2• 6 years ago

It's actually more like an abstract class! Even the Maybe monad has some implementation, it's just super simple :)

https://hackage.haskell.org/package/base-4.14.0.0/docs/src/G...

anchpop• 6 years ago

What you say is correct, but let me try and explain a little further. The Haskell function `getChar` is used to get a character from stdin. It has the type `IO Char` and is a totally, 100% pure. In fact, it isn't even a function, it's just a value.

You can write `getChar` as many times as you want, and you will get the same result every time, and it will have nothing to do with whatever character is being sent to stdin. Instead, what you will get is an instruction, saying "please get a character from stdin".

What the IO monad allows you to do is to compose instructions together. For example, you could write `getChar >> getChar". This makes a new instruction that says "please get a character from stdin, discard it, then get a character from stdin". The `>>` operator means "follow the instruction on the left, discard the result, then do the instruction on the right".

Your entire program is made by composing instructions like this, into one new huge instruction that specifies your entire program's behaviour. You assign that to the special name `main`. At runtime, the instruction is executed.

The only bit of compiler magic that's necessary is the code for interpreting the instructions and actually executing them. In theory, although haskell doesn't let you do this, you could write `getChar` yourself, and just return the same thing that `getChar` does, and it would behave identically.

This I feel is the simplest explanation for why monads are necessary in Haskell. They allow you to conveniently specify what you want your program to do, using only pure functions and values. Why do you want all values to be pure? Many don't because it's kind of a pain, but Haskell kind of exists to see if a lazy, pure functional language can be fun to use and many find that it is. Hope this helps someone!

choeger• 6 years ago

In fact, it isn't even a function, it's just a value.

What's the difference?

ridiculous_fish3• 6 years ago

Great description of IO, but I think it doesn't actually motivate monads. Your example of `getChar >> getChar` could be simply `[getChar, getChar]`. Why can't we just compose instructions into an ordinary list?

The answer is that we can, and Haskell used to work this way [1]! So as 'chowells' observed the monad-part of IO is almost incidental.

1: https://stackoverflow.com/questions/17002119/haskell-pre-mon...

thatcherc• 6 years ago

Ah, thanks - this is a really nice explanation. From reading a few "what is a monad" posts in the past, I get how the a monad can chain functions in sequence for imperative-style execution, but how the information like 'getChar' actually got in was never clear. It all comes down to the runtime I guess.

I'm favoriting this comment so I can come back the next time I forget how all this works :)

roenxi• 6 years ago

Although true; I'm not sure much of that provides clarity. Eg, "Your entire program is ... one new huge instruction" - that is true of any program, and it doesn't sound like a useful abstraction for reasoning about programs. The idea that getChar returns an instruction rather than a character is similarly not an obvious improvement from getChar() returning a character. It is quite subtle for someone to complain that getChar() returning a char is suboptimal.

Everything I've seen is monads are confusing because they solve a problem imperative languages don't think they have. As the article points out,

  function getDisplayPictureFromId(id) { 
    const user = getUser(id)
    if (!user) return
    const profile = getProfile(user)
    if (!profile) return
    return getDisplayPicture(profile)
  }

is totally fine and idiomatic in most imperative languages. Once a programmer starts chaining functions together (as functional programmers are wont to do) then the "if (!user) return" become a substantial blocker that needs a solution - which leads very quickly to monads and abstracting away IO.

agumonkey4• 6 years ago

to me the issue is twofold:

- cultural reliance on lambdas as the universal force (nothing against lambdas, but outside the fp world, there will be too much culture shock)

- representation as computation, the monad is only kinda building a graph to be evaluated, and each node can be wrapped with rules as you see fit

AnimalMuppet• 6 years ago

Hmm. Your last line makes me think that they're, essentially, using monads to represent S-expressions. That seems... somewhat clumsier than just using S-expressions. You gain a really good type system, though.

08-152• 6 years ago

the monad is only kinda building a graph to be evaluated

That's what the free monad does. Not every monad is a free monad, IO certainly isn't.

scns3• 6 years ago

Hopefully Java programmers are used to lambdas since Java 8

goto115• 6 years ago

Yeah this is like saying objects lets us perform IO in Java, and then going deep into explanations of what objects are and what rules they obey (Liskov substitution principle etc) - instead of just explaining that you call println() to write "hello world".

yomly4• 6 years ago

We often forget how much assumed knowledge (and accepted knowledge) went into learning OOP.

Turing Machine and Lambda Calculus are two entry points into computational thinking, is it really so alarming that if you've only learned one that trying to learn the other will make you feel like a beginner all over again?

smitty1e2• 6 years ago

I think the sticky wicket with Haskell is less the terse syntax and more the execution model.

Why not start enumerating the lines of a file, and show how we're building up a list of thinks, and there is no actual variable representing the line numbers because state is for Statists?

smitty1e2• 6 years ago

Thunks

centimeter2• 6 years ago

I think the hard part for most people is moving beyond Maybe/Either. It’s hard to find motivating examples when most languages lack denotational semantics and everything implicitly happens inside IO all the time.

Scandiravian3• 6 years ago

That is something I've struggled with as well. Do you have any suggestions for resources, that could help overcome that challenge?

centimeter2• 6 years ago

Nothing off the top of my head. The way I really got monads was just writing Haskell code. It's one of the very few programming languages with a clear denotational semantics for everything (as a result of being pure), and you end up with lots of simple problems like "how do I keep this value around and 'mutate' it" that are conveniently addressed by a monad like the State monad.

ryanjshaw• 6 years ago

If you come from a C# background, this book is excellent: https://www.manning.com/books/functional-programming-in-c-sh...

It does have some minor shortcomings in my opinion (e.g. if you haven't already started on the path of reinventing monads yourself you may struggle to immediately understand why this is a big deal and how it will save your life, the author should have used LanguageExt instead of their own library as LanguageExt is actively maintained and extremely well thought out, the book stops just short of becoming practical in the sense of "here's how to start a new C# project while thinking in functions", etc.).

You might also consider the LanguageExt guide itself: https://github.com/louthy/language-ext/wiki/Thinking-Functio...

fizixer• 6 years ago

So do you need monads in Haskell because that's the only way you could do some of the things that are trivial in an imperative language (albeit verbose and arguably inelegant)?

exdsq• 6 years ago

This is the paper that introduced them to FP, if you’re interested in the original reasoning.

https://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/b...

mrkeen3• 6 years ago

Koshkin3• 6 years ago

Yes. (For example, ML, being impure, does not need this.)

dependenttypes2• 6 years ago

Haskell only "needs" monads for IO (there are other alternatives to implement io in a pure language too though). The reason that they are popular in haskell is that they are convenient and the reason that they are not popular in ML is that it lacks higher order types and things like typeclasses.

y2bd• 6 years ago

Not exactly. For example, IO actually existed in Haskell before the IO Monad. It essentially used lists injected and retuned from the main function, plus the fact that Haskell is lazily evaluated (so those IO commands in the list wouldn’t be evaluated until main is run): https://stackoverflow.com/questions/17002119/haskell-pre-mon...

dependenttypes2• 6 years ago

Go is imperative and could really use some monads, especially for error handling. It has nothing to do with a language being pure or not really.

ape4• 6 years ago

That code that "is getting pretty ugly" seemed ok to me.

sfvisser• 6 years ago

Sure, that example wasn’t that bad. But if your specific monad is somewhat more complicated - e.g state, either, promise - and you’re using it all over the place all that boilerplate is going to obscure your domain logic pretty quickly.

Monads can help readability by focusing on the composition of your domain logic instead of writing out the same low-level boilerplate over and over again.

ducaale• 6 years ago

To understand monads, I think it helps to know a language where expressing such a concept is more natural. Although I do not claim to know 100% what monads are yet, coming across these features made it easier for me to understand the concept a little bit.

- Algebraic data types

- OCaml's let expressions

- F#'s computation expressions

I also think that it is important to write something that naturally requires the use of monads. One thing that spring to mind is Parser Combinators.

- https://fsharpforfunandprofit.com/posts/understanding-parser...

- https://www.youtube.com/watch?v=N9RUqGYuGfw

k__• 6 years ago

I think, the main benefit of FP is alsoits main problem.

Patterns like the monad are so abstract, that ob its own nobody knows what to do with it, but it makes them so very powerful.

OOP patterns, on the other hand, come from a more inductive source. They are more concrete, but also not as powerful. Easier to grasp, but less concise.

We need a step (or more) between the definition of FP concepts and their application, to make all this more approachable for the average programmer.

renox• 6 years ago

I wonder why it isn't ever described as a design pattern? For me, it is one..

mrkeen3• 6 years ago

I would call the State Monad a design pattern, I wouldn't call the List Monad a design pattern.

kbr• 6 years ago

I wrote an article with the same name! [1] The problem solving based approach seems to be the most relatable and easy for people to get an idea of what monads are. Nice work.

[1] https://blog.kabir.sh/inventing-monads

stopachka4• 6 years ago

Great work Kabir! : )

whereistimbo• 6 years ago

I thought I understand monad after reading the article, but then I read the comment and now I am confused what is monad (again)?

willtim• 6 years ago

I recommend reading the original "Monads for Functional Programming" paper by Phil Wadler, it's in a tutorial style and IMHO still better than any blog post explanation I have seen:

https://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/b...

kjgkjhfkjf2• 6 years ago

How many Monad explanations need to be written before we admit that the Monad is an unsatisfactory abstraction for practical purposes?

rumanator2• 6 years ago

How many Monad explanations need to be written before we admit that the Monad is an unsatisfactory abstraction for practical purposes?

That's really not true, is it? I mean, you only need to look at how monads are used to express results as return types to understand the practical usefulness of monads.

smegma22• 6 years ago

Why would we judge them by that standard? Monads are useful models for plenty of things. That has nothing to do with how many monad tutorials are out there.

mrkeen3• 6 years ago

These things are monadic:

Functions, continuations, state, IO, parsers, futures, streams, lists, transactions, LINQ, observables.

I can only think of one abstraction more useful - the function.

kjgkjhfkjf2• 6 years ago

I didn't say that monads aren't useful; I said that the abstraction is unsatisfactory. The world needs a new clearer concept to use instead of the monad, just as raft can be used instead of paxos.

codygman4• 6 years ago

I had a similar example today in the functional programming slack.

hello, quick question: i feel like there's a more elegant way to express this, but I'm struggling to come up with one:

    foo :: (a -> Bool) -> (a -> Bool) -> a -> Bool
    foo f g x = f x && g x

For those who aren't as familiar with Haskell, that is taking a function f and a function g, passing argument x to both, and then doing a binary and on their boolean result.

One answer suggested:

You can get fancy, but the “simple” version is almost always more readable:

    (not . null . f $ x) && (not . null . g $ x)

Which I find myself agreeing with in many ways, but for some reason leaves me desiring more.

The answer to that desire complements this article I think:

if f and g returned Maybe you could have:

    > f _ = Nothing
    > g _ = Just ()
    > x = ()
    >  (f x) <*> (g x)
    Nothing
    > import Data.Maybe
    >  (f x) <*> (g x) & isJust
    False
    > -- or to avoid <*> you can do
    > liftA f g x
    Nothing

If that's not clear, let me know what's confusing and I'll try to explain further

sudomakeup• 6 years ago

So, I'm a bit rusty on haskell but I have some notes on a similar concept. Essentially, fmap with a twist - instead of applying the same function to a list of values, you have a list of functions that you want to evaluate on the same value. "fpam". In this case, we're dealing with a list of size 2

  fpam :: [(a -> b)] -> a -> [b]
  fpam fns v = fns <*> pure v

after that then fold the list with boolean &&

  foo :: (a -> Bool) -> (a -> Bool) -> a -> Bool
  foo f g x = foldr1 (&&) ( fpam [f,g] x)

or alternatively with no helper functions

  foo2 :: (a -> Bool) -> (a -> Bool) -> a -> Bool
  foo2 f g x = foldr1 (&&) ( [f,g] <*> pure x)

for example

  Prelude> foldr1  (&&) ( [ (==3), (==4) ]  <*> pure 3 )
  False

Alternate implementations:

    import Data.List
    import Data.Function
    import Control.Monad.State
    import Data.Foldable
    import Control.Arrow((>>>))
    import Control.Monad.Reader
    import Control.Monad.List

    applyList :: [(a -> a)] -> a -> a
    applyList list = execState $ for_ list modify

    applyList2 :: [(a -> a)] -> a -> a
    applyList2 = foldr1 (>>>) 

    fpam :: [(a -> b)] -> a -> [b]
    fpam fns v = fns <*> pure v

    fpam2 :: [(a -> b)] -> a -> [b]
    fpam2 fns = runReader $ forM fns reader

    fpam3 :: [(a -> b)] -> a -> [b]
    fpam3 fns v = fmap (\f -> f v) fns

    fpam4 :: [(a -> b)] -> a -> [b]
    fpam4 fns = runReaderT $ do
      fn <- lift fns
      reader fn

codygman4• 6 years ago

Also see this related discussion: https://www.reddit.com/r/programming/comments/ij0qzl/comment...

codygman4• 6 years ago

Catching up on comments and kind of fuzzy, but this is pretty cool :)

    foldr1  (&&) ( [ (==3), (==4) ]  <*> pure 3 )

smegma22• 6 years ago

`on` runs a binary function by first running a unary function on each argument.

  Prelude> import Data.Function (on)
  Prelude Data.Function> :t on
  on :: (b -> b -> c) -> (a -> b) -> a -> a -> c
  Prelude Data.Function> f = undefined :: Int -> [Int]
  Prelude Data.Function> g = undefined :: Int -> [Int]
  Prelude Data.Function> :t ((&&) `on` (not . null . ($ x))) f g
  ((&&) `on` (not . null . ($ x))) f g :: Bool

Alternatively in Control.Arrow there's a 'fanout' operator &&&:

  Prelude Control.Arrow> f = undefined :: Int -> Bool
  Prelude Control.Arrow> g = undefined :: Int -> Bool
  Prelude Control.Arrow> :t uncurry (&&) . (f &&& g)
  uncurry (&&) . (f &&& g) :: Int -> Bool

Of course it's still probably simpler to just write it out in this case.

codygman4• 6 years ago

Also see this related discussion: https://www.reddit.com/r/programming/comments/ij0qzl/comment...

dllthomas4• 6 years ago

I'll occasionally hide the monomorphic && and define something like:

    class Predicate a where
        (&&) :: a -> a -> a
        not :: a -> a
        etc :: ...

and then define the obvious instances for `Bool` and `Predicate b => a -> b`

It's really nice to be able to just write `(> 6) && even` or `isAlpha || (== '_')`

Inventing Monads

Related Stories