I seem to be monad proof - cannot understand them from any explanation whatsoever. If I'm not alone then it's going to be hard to hire people that get it - on top of how hard it is to hire skilled people at all.
It's not it, of course, but that's all you need to know. You can open up the js console in your browser right now and play around with `map` vs `flatMap` since lists are monads.
It's not a very useful function on lists, but if you take pains to simulate an optional type with it, where an empty list is Nothing/failure and a list with a value indicates Just/success, you can see how it might be an exciting form of control flow: chaining together optimistic functions, but short circuiting if any of them fail. Happy path only programming.
I wouldn't worry too much if this is yet another shit explanation. Monads will eventually be added in earnest to your language of choice, you will use them, and think "oh, why could nobody explain that?"
> A monad is something that you can use `flatMap` on that cannot act in a surprising way. That's it.
Let's remove all the complexities that are introduced by the static type system for a moment, and focus on the essence. To illustrate the key point, let's use a dynamically typed logic programming language such as Prolog, where we think in terms of relations instead of functions.
Suppose we have a predicate definition of this shape:
pred(S0, S) :-
goal_1(S0, S1),
goal_2(S1, S2),
goal_3(S2, S3),
...,
goal_N(SN1, S).
You can think of monads as mechanism to make this cumbersome explicit passing of arguments implicit. For example, since the arguments that are passed around follow such a clear pattern, we could write the example above equivalently as:
pred -->
goal_1,
goal_2,
goal_3,
...,
goal_N.
( (7^7^7`mod`5`mod`2)==1, [False,True]!!(7^7^7`mod`5`mod`2) )
(True,False)
In GHC, there is a dedicated flag to spot such cases (-fwarn-type-defaults).
In general, the guarentees that the type system actually gives and also the ways to specify them appear somewhat unfinished and are also quite hard to understand, often necessitating semantic restrictions and syntactic extensions. For further examples, see for instance:
https://stackoverflow.com/questions/27019906/type-inference-...
https://stackoverflow.com/questions/14865734/referential-tra...
0. Integer is arbitrary precision while Int is bounded, machine dependent (eg. 32 or 64 bit). They are both instances of the Num type class as well as the Integral type class as we'll see later.
1. Numbers without explicit type signatures are overloaded (aka. constraint polymorphic):
λ> :t 1
1 :: Num p => p
2. As per https://www.haskell.org/onlinereport/decls.html#sect4.3.4 we have
default (Integer, Double)
3. The type of the list index operator is:
λ> :t (!!)
(!!) :: [a] -> Int -> a
Right, so in the above example if we check the type of 7^7^7`mod`5`mod`2
λ> :t 7^7^7`mod`5`mod`2
(7^7^7`mod`5`mod`2) :: Integral a => a
λ> 7^7^7`mod`5 :: Integer
3
λ> 7^7^7`mod`5 :: Int
2
default ()
λ> ( (7^7^7`mod`5`mod`2)==1, [False,True]!!fromInteger((7^7^7`mod`5`mod`2)) )
(True,True)See https://wiki.haskell.org/Polymorphism for details on parametric (ie. unconstrained) vs. ad-hoc (ie. constrained) polymorphism. In short the difference is that ad-hoc is parametric + one or more type class constraints. Eg. in:
λ> :t fmap
fmap :: Functor f => (a -> b) -> f a -> f b
You people live in an ivory tower.
A monad is a mathematical idea. It has some learning curve, some inherent complexity that you can't magically solve.
The post you're mocking attempts to draw a helpful analogy. Maybe it helps the original author who said they couldn't find an explanation of monads that they liked. Maybe it doesn't help.
I don't see how name calling such conversation as "ivory tower" helps anyone
Not here. A monad is a programming idea. It bears some similarity to a mathematical idea, but we aren't really doing category theory here. We're doing programming.
The programming idea is simple: Anything that implements certain methods with certain semantics. That's it.
The stated intent of the post is "to provide an understandable notion of Monads to people who do not get them", so it seems terribly ignorant of the audience to assume that they will know Prolog, a language known for incredibly arcane syntax that has mostly been unused except for a handful of circumstances, outside of the 1980s.
The author wants to draw a parallel between Monads and Prolog's execution, however how many programmers understand Prolog? Of those programmers, how many haven't grasped monads? Even I, who has some Prolog knowledge, now has the mental and cognitive load of having to parse the Prolog that I haven't seen used properly in perhaps 6 years, on top of having to understand the analogy to monads, on top of having to understand the description of monads.
If n-gate still existed, I would pay them to review this comment chain, personally.
The code example basically requires no Prolog knowledge to understand. It's basically just psuedo-code.
Does understanding how a database works on a level past what most industrial programmers need to, say, leverage the value of an index make someone an ivory-tower resident? How about understanding how Paxos (ha) or Raft work? For that matter, does reading any computer science paper take me out of the realm of being a "blue-collar" programmer or does it depend on how much the paper stinks of "ivory-tower-ness?"
Have I made my point yet?
How does that relate to “pipe operator” as in https://github.com/tc39/proposal-pipeline-operator
Are monads also linear types? I mean, if I have a monad which represents system IO state, each value of system state can only be consumed once in actual execution, I can’t split the IO state in two and print different outputs on each branch. But I can do that in a conditional expression because only one branch is ever actually realised. For IO state, data branching is only allowed when guarded by control branching.
That's a part of it, for instance see:
https://philipnilsson.github.io/Badness10k/posts/2017-05-07-...
I recently wrote a note related to this that had a useful exchange:
>> When you see a "do" block, where do you look to figure out what it's actually doing?
> If you need to know, you look at what consumes the result. If it's abstract (say it's a top level binding `... -> m a` where the m is abstract) *you don't _need_ to know "what it is actually doing" - it should be correct for any choice of* `m`.
The behavior, and the "laws" or perhaps general far-reaching properties, are the more important part of Monads I think.
> How does that relate to “pipe operator” as in https://github.com/tc39/proposal-pipeline-operator
The items in the pipeline don't have a set of laws that let you know what's going on for sure without looking at the implementation I guess.
{
X:value-that-we-care-about,
Y:something-we-only-care-about-occasionally-if-at-all
}
with error monads we don't always care if something failed (like a write) but we probably want to keep that information for later, so it just gets hidden and we can pretend we're just passing around a value (see https://fsharpforfunandprofit.com/rop/ )
I'm not particularly clear on how Haskell does the IO monad, but basically the hidden value is what lets the compiler keep track of what was done pre/post IO, allowing you to thread-the-whole-world through an IO call.
"Do" uses the same trick as that prolog example, by threading previous calculations through a function call you can force
Do
Foo1
Foo2
Foo3
Monads are state/system backdoors for pure functions. Life would be pretty cool if we could just map/filter/reduce everything, it's a beautiful model and ripe for insane optimization. Sadly programs like that aren't useful, and programmers always want to do gross animal stuff like writing to sockets or files. Enter the humble monad, a way to pass something like a database connection, a logger, a system IO instance, or whatever into your cool nest of map calls.
John Ousterhout talks about this problem in A Philosophy of Software Design. Sometimes you need to carry things around, like a rendering context, a browser window, whatever, and you're give a couple of imperfect options:
- Make it global
- Thread it through literally everything
(React people might know #2 as "prop drilling", and they might know #1 as hooks)
Monads are infrastructure to help you do #2, since #1, well, people don't like it.
half(x)
double(x)
triple(x)
you can easily do things like:
double(half(triple(13)))
Or a la pipes:
triple 13 | half | double
But now what if you want to print something in `half` without a global? Well, I guess it's half(x, printer) now. Hmm and now `triple` has to carry that around too, so it's triple(x, printer). Well, that makes me think everything gets a printer, so it's double(x, printer) now too.
Well, printing is cool, but now we're a real company and real companies log everything. I... guess we're making new functions? half_log(x, logger) and triple_log(x, logger) and double_log(x, logger). And... new pipelines? Ugh.
At this point you might be thinking one of a number of things:
- Are globals really that bad?
- Can OOP fix this (dependency injection, builders)?
- Surely there's some kind of framework for this.
And if you're a functional programmer who's super not into globals or OOP, you might start seeing the appeal of #3 there. Et voila, a whole bunch of functions that handle this "pass an extra blob into your pipelines" thing.
This dichotomy is fundamental, which is why I'm sticking on it here. Either you have to deliberately hand this piece of data down into the scope you're working with, or you can summon it from any scope. There really are no other options.
But doesn't that mean that you're agreeing with me that OO and monads are doing the same thing (at least in this regard)?
And, can someone explain to me how the type system works here? I had thought that an advantage of monads were that you just had to change the type signature to take a monad rather than to take an int, but once you did that, it could take any monad. But that won't work, will it? If you're going to try to log from that function, then it has to be a monad that logs, doesn't it? It can't just be a generic monad; it has to be a specific one.
Re: type system, AFAIK you do like (let's assume something Go-ish here):
type Integer interface {
GetValue() int
Mul(i Integer) Integer
}
type Logger interface {
LogMessage()
}
type DataBlob struct {
value int
message string
}
func (db *DataBlob) GetValue() int {
return db.value
}
func (db *DataBlob) Mul(i Integer) Integer {
db.value *= i.GetValue()
return db
}
func (db *DataBlob) LogMessage() {
log.Println(db.message)
}
func triple(db *DataBlob) *DataBlob {
return db.Mul(&DataBlob{3, ""})
}
In this way, you can always implement more interfaces onto DataBlob, and then modify your pipeline steps to take advantage of the new functionality. This example isn't really perfect, but it's reasonably illustrative. The thing is getting the compiler to know you can do different things with a given piece of data. In Go that's interfaces, in Haskell that's typeclasses, in Rust that's traits, blah.
P.S. This [0] Rosetta Code example made it pretty clear to me, so if you're the same kind of thinker maybe it'll help you.
- lists are monads that provide multiplicity
- options are monads that provide nullability
- try wrappers are monads that provide failure semantics
- futures and promises are monads that provide asyncrony
- either is a monad that provides duality
… and many more. The key concept here is that you wrap computations in some behavior before executing them. there are many problems that can be monadefied.
The problem is that learning about monads comes with a lot of threads to pull about category theory and it’s use in computation. This is where I feel folks get lost.
Monads are tremendously useful and understandable. Many go full theory when teaching them and that is regrettable.
The programming world is filled with concepts that beginners find extremely difficult to comprehend from explanations:
- pointers
- closures
- recursion
If you have a binary tree whose leaves are also binary trees, is that meaningfully different from a single grafted binary tree? Not really.
If you have a sequence (list) of sequences, is that meaningfully different from having a single sequence? Not really.
If you have an option of option of bool, is that meaningfully different from having a single optional? Not really.
More precisely, if you don't care about the difference, structures that are monads let you smooth over the seam between nesting levels.
The flatMap operator lets you extend a data structure at each of its leaves. That is, you can map over each leaf and replace it with another structure of the same kind, then smooth over the seam.
The connection with computation comes about by imagining the data structure as the history of outputs of a process; a trace. You can extend a program trace by specifying what to do next (via flatMap). Clever choices of data structure give you interesting alternative models of computation. But, this is an application of modeling with monads. It's not what a monad is.
Try solving a non trivial problem on Haskell. You may not fully understand monads but you should get a feeling for it.
Conceptually, a "pure" function is something as `A -> B`, so all information about its internal (e.g. side effects) lost: we put something of type A but we can only observe a result of type B.
The idea of computation monads is to attach the result type of the function with a "constructor" T, then the type T B is used to "restore" (or to reason about) the lost information.
In composing such functions, T X (for some result type X) is all information we need, then this explains naturally the third rule of the Kleisli triple `f: A -> T B; g: B -> T C`: A -> T C
It can be helpful to just take the word "monad" out of your brain and work up from understanding the idea of a functor first, then gradually understand what a monad is.
In the end, I think, monads are not that exciting outside the world of pure FP :) https://twitter.com/plt_borat/status/228009057670291456
The "return" monad operation does a very simple thing: given a value, constructs a box that is going to generate that value once you press the button. Not very useful in itself, but the point is that that value can be used for further computation. The "bind" operation precisely takes another monad and a function, so now we have two monads: the first one is provided by you and the second one is the result of the "bind" operation. Think the first monad as being "embedded" in the second one. When you press the button on the outer monad, first the button on the inner monad is pressed and a value is generated; then the value is mapped through the function; and then the result of the function is the value generated by the outer monad. In practice you extended the inner monad, doing some more computation (the function) after it had executed.
In the case of the Haskell IO monad, you can't really press the button inside your program: there is no way to extract values that were put in a IO monad. Still, on object of the IO monad encodes what you want the program to do. Basically the Haskell interpreter/compiler gives you the opportunity the press just once the button of a single IO monad, precisely of the one that is given by the main symbol (which has type "IO ()"). By composing monads in the right way, you can arrange your program to do what you want.
In other words, a monad like IO, where you can't press the button yourself, allows you to express precisely what a program with side-effects should be: something for which you cannot know the result (you cannot press the button and see the generated value in the program) unless you really execute it and commit to the side effects (which is what happen when main returns something and the single allowed button press is executed on that thing).
https://fsharpforfunandprofit.com/rop/
You won't believe it's about monads!
Monads are the same thing, but for functions.
They adjust the output of one function so it can become the input of the next one.
it's either value or dividing by 0 error :)
How do you handle state in a language like Haskell that doesn’t have mutable state? You pass a data value between functions keeping track of everything, as an extra argument. Imagine the boilerplate of that! Every function suddenly needs an extra argument for Data, regardless of if it needs it, to keep it around. The State Monad deals with that boilerplate.