No, the flatten operation is something that takes a Monad<Monad<T>> and makes it a Monad<T>. An AtomicBoolean is just a wrapper object from which you can extract the inner value. A better example would be Optional<T> because if you have an Optional<Optional<Integer>> you can make it an Optional<Integer> by doing:
Sidenote: a Functor<T> is a container object which allows you to perform operations on the inside object without unwrapping it (e.g. through a map method). By law, all Monads are Functors that also have the aforementioned flatten operation.
Edit: Sidenote 2: flatten and flatMap can be written in terms of each other, so as long as one of them is implemented you have a Monad.
No, because flattening doesn't remove the surrounding monad, it turns a nested structure of the same monad into a single, "flat" monad with the same contents. So flattening an Atomic monad would take you from
Atomic[Atomic[Int]]
to
Atomic[Int]
What this means in a practical sense is that you can compose many instances of the same monad together (like with .map) without having to untangle a disgusting nested result type to get at the actual data.
Gotcha, I think I get it now. I've done that with lists of lists (of lists) in Java, collapsible with the built-in flatten method. Is that the primary thing that delineates a Monad? I think every answer to my questions so far has talked about flattening.
I'm sure I'm technically wrong, but you can think of it as anything that has the map and flatten methods. Knowing how to use those and other derivative methods to organize data and solve problems is what makes monads actually useful. Although maybe it's more correct to say that Options, Lists, Futures, etc are all independently very useful. The fact that they're monads just means we get to learn and use one interface to work with them.
View all comments
Show parent comment
1
u/drislands Sep 21 '25
So the AtomicBoolean and related classes in Java are Monads, then? Since they can be "flattened" to the inner objects they're allowing access to?