I tried learning Haskell for a decent chunk of time and could make some stuff, but despite trying to learn, I still could not tell you what a monad actually is. All the explanations for it seemed to make no sense.
(I'm trying very hard not to fall into the trying-to-explain-monads trap!)
You need to be able to "wrap" values and then also "wrap" functions in the way you expect. That's literally it.
Btw, the list monad example is stupid imo and borderline misleading. The promise/nullable/Either examples are better. you "wrap" a function by putting it as the only value in a list, and "map" pretty much acts as your function wrapper, but technically this you need to jump through a couple hoops to make it monadic, and I'm just not sure the metaphor is helpful here
λ> do { a <- [1,2]; pure a; }
[1,2]
-- oh so it returns the list unchanged
λ> do { a <- [1,2]; b <- [3,4]; pure a; }
[1,1,2,2]
-- no what is this spooky action at a distance
λ> do { a <- [1,2]; b <- [3,4]; pure [a]; }
[[1],[1],[2],[2]]
-- ...
λ> do { a <- [1,2]; b <- [3,4]; c <- []; pure [a]; }
[]
λ> do { a <- [1,2]; b <- [3,4]; c <- [5]; pure [a,b,c]; }
[[1,3,5],[1,4,5],[2,3,5],[2,4,5]]A bigger issue is that you're missing a piece. If you can "wrap" values and "wrap" functions such that they operate on wrapped values, you (probably) have a functor. To be a monad you also need to have the ability to turn multiple layers of wrapping into one layer of wrapping. For lists, that's "flatten".
I said "probably" above because there are rules these pieces need to follow to behave well. They're pretty simple but I don't think we need to dig into them at this level of discussion.
I might have some inaccuracies in how I state this since I’m not from a functional programming background, but I think of monads as an abstraction of chaining functions over a value such that each returned value can specify what further transformations it supports, and particularly in such a way that generic transformations (like sequence reversal) can easily be applied, and errors or empty values can be accounted for within the control flow.
I think sometimes people call this a “fluent API”, but I would never call it “a generalization of callbacks” or of promises.
Anyway there’s a much more mathematically precise way of stating it but this is my intuitive caveman way of thinking about it.
https://hackage.haskell.org/package/base-4.21.0.0/docs/Contr...
https://book.realworldhaskell.org/read/monads.html
A common metaphor for monad is "executable semicolons". They are effectively a way to add (structured) hook computations (that always returns a specific type of value) to run every time a "main" computation (akin to a "statement" in other languages) occurs "in" the monad.
It's sort of like a decorator in Python, but more structured. It lets you write a series of simple computational steps (transforming values), and then "dress them up" / "clean them up" by adding a specific computation to run after each step.
(but do I appreciate the effort you put into your reply - reading that monad's are more like interfaces is new information to me, and might help down the road)
Typeclasses are a distraction, the point is computation ignoring annoying contexty stuff (file not found errors, null on failure, etc) and there's dozens of examples in literally every language ever.
Not all problems are solved with a technical definition.
Where did you get the impression that Haskell people don't realize that code patterns are a thing in other languages, or that monads don't exist in other languages?
Besides the syntactic sugar of "do notation", what Haskell has that most other languages don't have is the ability to abstract over monads, since it has higher kinded types. That is, you can write a generic operation like
mapM :: (Traversable t, Monad m) => (a -> m b) -> t a -> m (t b)
Example is best for illustration. I'll use a made-up syntax.
// 'Maybe' is a monad wrapping any value type T that can be null.
class Maybe<T> {
// The value wrapped by the monadic value
value: T;
// A constructor to make a Maybe monadic value from a plain value T.
// This is called 'unit' or 'return' in Haskell, or 'lift' in other languages.
// It's really a constructor.
static wrap(v: T) Maybe<T> {
return new Maybe { value = v }
}
// then() applies fn on the unwrapped value. fn returns a Maybe<T>.
// This is called 'bind' in Haskell, or 'flatMap' in other languages.
then(fn: (T) => Maybe<T>) Maybe<T> {
return this.value == null ? Maybe.wrap(null) : fn(this.value);
}
}
let a = Maybe<int>.wrap(4) // construct a monadic value
let b = a.then(x => Maybe<int>.wrap(x + 1)) // add 1 to it
let c = Maybe<int>.wrap(null) // construct a null monadic value
let d = c.then(x => Maybe<int>.wrap(x + 1)) // safely handle null; d is null
let e = Maybe<int>.wrap(5)
.then(x => Maybe<int>.wrap(x + 1))
.then(x => Maybe<int>.wrap(x * 2)) // chain the calls
let f = Maybe<float>.wrap(5.0) // The same Maybe on a different type
.then(x => Maybe<float>.wrap(null))
.then(x => Maybe<float>.wrap(x * 2)) // chain the calls; safely handle nullExamples of monads are Promises and Elvis operators (for values that can be nullptrs). In a sense exceptions as well. Having heard this I think if you do a second pass at the type definitions, I think you may be able to parse them out
It really is just "a wrapper for values that sticks around when you do something to the values".
Think of it as a coding pattern, and it's much easier to grok
It's handy for IO because, well, did you see the examples I gave? A monad lets you basically ignore the failure mode/weirdness (the async stuff in the context of promises, null type in the case of Elvis) and worry about the computation you actually want to be doing.
Other places you might apply these would be fileio (file not found? cool, don't care, deal with it later) or networking (as long as the connection's good, do this.)
Promises are wrappers, I see that. How are exceptions wrappers? They stop the code at the point the exception occurs and unwind the stack. They don't allow you to continue doing stuff and deal with it later.
> A monad lets you basically ignore the failure mode/weirdness
I just don't see how this works out in practice?
Ok, I defer dealing with file not found. Does that mean I know perform heavy computation and parsing on something that does not even exist. Wouldn't it be way easier to just do an early return and encode that the file exists in the type? And how does it play out to let the user wait for you doing something and you at the end coming around, well actually the input file was already missing?
And then you have some intermediate layer that needs to store all the computation you are doing until you now whether something succeeded or not. All this to save a single return statement.
It's not about saving a single return statement, even in the elvis case. How many times have you written code along the lines of "if this isn't null do this, otherwise return. If the result of that isn't null, do this, otherwise return" etc etc.
Elvis ops are a small QoL change, Promises are essential to async Exceptions (much of the time) are kind of a "catch it pass it on" logic for me, and man do I wish I didn't need to write it every time.
With networking this really shines, or really just anything async etc
Yeah that sucks, but why would you write it that way. I thought it is common to write "if this is null return, anyways: do this, do that."
> Promises are essential to async Exceptions
I don't see that either. If errors are specific to functions then there is only one case where I handle them, so it doesn't save something to put these checks elsewhere. If they can be accumulated over many calls, then they should be just part of the object state (like feof), so I can query them in the end.
Nan-in served tea. He poured his visitor’s cup full, and then kept on pouring.
The professor watched the overflow until he no longer could restrain himself. “It is overfull. No more will go in!”
“Like this cup,” Nan-in said, “you are full of your own opinions and speculations. How can I show you a Monad unless you first empty your cup?”
A monad is a function that can be combined with other functions.
It's a closure (or functor to the cool kids) that can be bound and arranged into a more complex composite closure without a specification of any actual value to operate on.
It's a lazy operation declaration that can operate over a class of types rather than a specific type (though a type is a class of types with just a single type so this is more a note on potential rather than necessary utility) that can be composed and manipulated in languages like Haskell to easily create large declarative blocks of code that are very easy to understand and lend themselves easily to abstract proofs about execution.
You've probably used them or a pattern like them in your code without realizing it.
I can’t even make stuff with fundamental groups.