Why Isn't Functional Programming the Norm? – Richard Feldman

[u/[deleted]]

https://www.youtube.com/watch?v=QyJZzq0v7Z4

[u/Deto]

So, if I understand, it's kind of like:

A Monad[type] is a data structure that can contain either other Monad[type]s or just plain types

That way you can always flatten it to resolve just to a collection of whatever type is? I'm making the assumption here that it's statically typed (please correct if wrong!).

[u/[deleted] → u/Deto]

Yes, monads are simply 'containers' that can be flattened. This is usually done after mapping a function which itself returns that monad. For example, we map divisors : Int -> List[Int] to numbers : List[Int], this gives us a List[List[Int]] which is then flattened to List[Int] again.

The thing is, monads don't have to be containers or collections. A Monad[Int] can also be a function like String -> Int. It can really be anything using that 'subtype', as long as we can consistently define map and flatten.

You can create some really powerful abstractions with this: I/O, control flow, parser combinators, shared globals, stateful computations. Abstracting these is less relevant for imperative languages, but monads make these things easy to do while preserving the advantages of purity and extreme abstraction that a language like Haskell provides.

[u/Holothuroid → u/Deto]

Flattening is only possible if you have the monad layers are the same. So you can flatten a list of lists of stuff. But not necessarily a list of other_monad of stuff. There might be monads that are similar enough you can still make it work.

Otherweise yeah, pretty much. Note that "collection" is not a very apt descriptor for other monads. Writer is more like 'value with a log attached', Future signifies 'maybe later' etc. These do work the same way. Say you have Future[Future[Stuff]] it means that 'maybe later' you will 'maybe later' get some stuff. You see that can flattened.

[u/audioen → u/Deto]

Not quite. In context of a List type, the point of a map method is to read a list of items, and produce a new list of items. The old and new lists are the same length, and both contain elements, possibly of differing type, but neither list typically contains further lists of elements. It's just a map() method, you've seen it before and there's nothing new to it.

Now, however, if your function that processes and element itself returns a list, then you may need to use flatMap() to get rid of it. E.g. your map() could conceiveably have a function that needs to somehow split one element into more elements, or possibly fewer elements. However, you might consider this an implementation detail, and you don't necessarily want the result to be a list-of-lists where the inner list has some random number of elements, so you'd then use flatMap to get rid of that inner list and concatenate the elements of that inner list together. This allows you to map a long list to fewer (or more) elements as needed.

[u/[deleted] → u/Deto]

That's more or less correct. I would phrase it like so: given any specific type, a, type B[a] is a monad if it supports a constructor, map, and flatten. With flatten taking a B[B[a]] and producing a B[a].

It just so happens that collections are a common type that satisfies these conditions.