So a monad is basically a specialized object for converting to and from a datatype. So FP has specialized objects. Monad marries OO with FP in that sense. In C++ I would do this pattern with a class because it makes sense to encapsulate it there. Or at least a namespace.
Change my mind.

https://en.wikipedia.org/wiki/...

I understand this as a wrapper of data along with some meta-information.

In that sense, the IEEE floating format with its special bit patterns for things like NAN can be seen as one (albeit somewhat hacky) possibility how to implement that in practice.

Idk it just looks like a inteface to me...

One thing that struck me when learning about composing functions was can the same concepts be applied to objects. Essentially functions are first class (in my mind that means type/object). So does it make sense to compose other types/objects. Not sure it does, but the idea makes me wonder if that is useful somehow. I am still very fuzzy on the composition of functions to be honest. Still working through a book I am reading right now.

@Demolishun you're close to what a monad actually is supposed to do - it makes composing things easy for things that you want to treat as something more than a blob of data. In a sense, it is a generalization of ye olde function composition.

I like to think of the standard FP interpretation of monads as a sort of baggage handler - each function that returns a monadic result basically returns the actual result data plus some "baggage". When you want to compose this function with another that also returns some "baggage", the baggage handler comes in and figures out how to run both functions and deal with the pieces of baggage so produced to generate one (monadic) output.

Eg. For the IO monad (theoretically) the entire world is the baggage. Monadic composition allows you to sequence IO operations.

Writer is a monad that carries an internal logging system as the baggage. Monadic composition sticks logs produced by functions together.

@Gregozor2121 at the end of the day, monads in FP are just a design pattern, you can get by just fine without them.

@Fast-Nop not quite just a wrapper with meta information, monads also need to obey certain laws and behave in certain ways (which are there to basically just guarantee that you can compose freely and it'll *always* work, at least theoretically).

@RememberMe Which basically means that if you have a whole bunch of computation going on, and if some input data are invalid, then depending on the dependency traces, the output data may or may not be valid.

E.g. if the valid data are so that the invalid data are not needed in that particular scenario, then the result is still valid.

The kicker being that each stage only cares about stuff within its own scope, but everything propagates properly to the output. And that this keeps working even if you re-wire the computation pipeline.

Which is especially nice for IO data coming from a source that gives some sort of validity flag with them. Like sensor values that may be flagged as invalid because the aggregating unit has determined that sensor to be broken.

@Fast-Nop yeah, that's a very useful pattern, the generalization of that is composition using optional types that are monads.

Haskell's standard optional type, Maybe (or Either if you want to stuff an error message in there, not just a validity flag) does this for any kind of value.