Monads for Clojure Programmers
cuddly-octo-palm-tree.com
cuddly-octo-palm-tree.com
The reason they are hard to explain in a language without HKT is the same reason why List[T] would be hard to explain in a language without generics.
edit: The article is impressive. It's just it feels like a different thing to me to than what monads are in haskell. I guess it would have to be.
Then the common abstraction of the monad can be used to interact with these things that all share this common property, in a unified way.
Finally, higher kinded types is what makes the idea of _many_ different things that can be monads manageable for the programmer, because if the underlying thing that the monad represents keeps changing into different forms, it's very easy to loose track of what structure or concept it currently represents without the types to keep track of that for you.
The interesting thing about 'monads' isn't bind and return. The interesting thing is the Control.Monad functions that build on them, and by making something that conforms to the monadic interface, you get to use them: https://hackage.haskell.org/package/base-4.15.0.0/docs/Contr...
Just like the special thing about iterators isn't that you can get the "next" thing. That's not impressive on its own. The magic is in the tools you get that can generically use and manipulate iterators if they conform to a particular interface.
1. How many things "fit" this abstraction?
2. What does this abstraction let me say?
The abstraction "Monad" has many inhabitants, and the Control.Monad module shows that it lets you say many things -> it is a very useful abstraction. The abstraction "Applicative" has many more inhabitants, but lets you say fewer things -> it is still a useful abstraction.
The other big benefit of monads is that they can automatically work with syntactic-sugar such as do-notation to allow non-linear code to be written in a linear way.
Monads and syntax, even without HKT, allow the user to write their own async-await, option, result, list, etc. expressions.
The usefulness of it, to me, is how the bind/flatmap can be generic over type constructors, but type constructors aren't a clojure concept. It's a static typing thing.
To have an interface for monads, you need to have HKT don't you? To declare the type of bind?
It could be useful otherwise. It would just seem like a slightly different thing.
I really disagree with the notion “HKT are necessary for monads”, though: they’re necessary to statically check that your monadic code is correct, but asside from things that rely on return-type inference, you can just implement those type-checks as runtime checks (or leave them out entirely): if the architecture of side-effects in your app is arranged around monadic principles, you can write all the same generic transformations (and, in fact, designing your dynamically typed code this way can get you a good fraction of the correctness benefits of static typechecking)
I've given up on the monads in dynamic languages outside of really strict confined situations (validation for instance). I think it's ultimately a bit silly to do something like `StateT` in Clojure rather than just using an `atom` or whatever. What you lose in referential transparency and purity, you more than make up for in sanity over the long haul.
The scales would tip if Clojure had stronger typing options, but for now, using the idiomatic stuff is the way to go. Although, spec could probably be used in a pinch, but it's kind've hot garbage compared to compiler checked types (imho!).
(You could probaby go further and say "without semantic support.")
1. pure :: T -> M<T>, and
2. Any one of the following three (you can derive any of these from any other)
join :: M <M<T>> -> M<T>
bind :: (M<A>, A -> M<B>) -> M<B> -- sometimes called "andThen"
pipe :: (A -> M<B>, B -> M<C>) -> (A -> M<C>)
If they interact with each other in a "sensible" way (the "monad laws"), you have a Monad.
---
What things fit this abstraction? I think the most familiar one to mainstream programmers would be Promises. If you have a Promise<Promise<A>>, you can join them together to get a Promise<A>. If you have a Promise<A> that you need to do some further work on, using the bind operation with a function (a -> Promise<B>) lets you "bind a name" to the result of the first promise and return a new Promise<B>.
If you'd like to be explicit about null-checks, then the Option<A> type lets you build up a computation without writing `if (foo != null)` everywhere. A variant, Result<E, A>, lets you stop on the first error. Tracking explicit error information in this way has been invaluable when taming a large ruby codebase - see the dry-monads project.
Any time you want to describe interactions with a system, this abstraction gives you something like the "command design pattern" on steroids. I have used Transaction<A> types to representing database transactions, ensuring that arbitrary IO doesn't happen inside a transaction (you can't unsend an email if the transaction rolls back). A function of type ((Connection, Transaction<A>) -> IO<Result<E,A>>) executes the DB operations inside a DB transaction and either returns the transaction result or an error.
None of this is "we want to change the world lol". I want to be able to notice the common elements between several type constructors, and be able to work on them using a common vocabulary, instead of reinventing wheels.
They are. It's the generic notation that you'll find in Java, C#, Rust, etc.. They are statically typed languages, so instead of just saying [vector] like in Clojure, you would say Vector<T>, where T is the type of the things in the vector. Vector<T> by itself is not a type. You can think of it as a function that takes a type and returns a type: with Int, you would get Vector<Int>, with String, you would get Vector<String>. This isn't limited to collections: Option<T> represents a value that may or may not be there, Result<R, E> represents something that can be either a result, or an error.
For the other collections, {maps} would be Map<A, B>, lists would be List<T>, sets would be Set<T>. Note that T, A or B don't mean anything specifically, they are variable names. Usually people use very abstract names for generics because they are very abstract. But you could also do List<Element> or Map<Key, Value>.
> Are promises and futures always monads?
Not all the time. For example, JavaScript promises aren't monads. There's a relatively popular discussion about it here: https://github.com/promises-aplus/promises-spec/issues/94.
As another example of a monads, there Option<T>, called Maybe<T> in Haskell. It's used for a value that could be there. Java has Optional that looks like it, but isn't a monad since it doesn't follow the monad laws: https://www.sitepoint.com/how-optional-breaks-the-monad-laws....
A good way to think about monads is to think about them as mathematical objects. They respect some rules, and thus have some properties. When you're implementing something in a language, like promises, you can choose to have them respect the monad rules, so that they can have the monad properties. You can also not do that (like they did in JavaScript), and so people won't be able to use them like monads.
In particular, unless our Set identifies its items in a way that forces a = b to imply f(a) = f(b), eliminating "duplicates" will sometimes eliminate things which can be distinguished by some function d.
This means that map(d, map(f, set)) might not always equal map(compose(d, f), set), which is required for a functor (which is more general than monad - all monads must be functors, not all functors are monads).
> Are promises and futures always monads?
Only if you can construct the necessary operations (or if they are provided), and they relate to each other correctly. For example, if you have a value m of type M<A>, (join (pure m)) should be identical to m.
The language you're using also needs to be able to usefully do something with this fact, or it's just trivia. In Haskell, we can define a type class called Monad and write operations that work on any monad, without knowing or caring which one is in use (that's the caller's job to decide). This would be hard-to-impossible to do in a less expressive language like C.
Monads are a tool. And yes, they can be used for things like having side effects in pure code or allowing for the chaining of functions, but those are just tangential benefits. Fundamentally, monads are just a way to categorize data, and the downstream results of that data. In the end, this gives us the ability to codify what we - as programmers - already know, and therefore depend on.
Consider the following mad-lib:
> Any value computed using the result of ____ must also - by definition - be the result of ____.
Now, let's plug in a simple example with "asynchronous function":
> Any value computed using the result of an asynchronous function must also - by definition - be the result of an asynchronous function.
If I call a function call `httpGet` that returns `Future<Response>` and then I take the response and parse the HTML into a DOM object, I know - as a programmer - that the DOM object is of type `Future<DOM>`. I know this whether or not the programming language I'm using is dynamically typed, supports higher-kinded types, or not.
Whether or not you prefer to live in Haskell land, Go land, Clojure land, or Flatland, monads are just a tool for you - the programmer - to categorize your data and codify (at compile time and/or runtime) what you already know.
I just find that when I read most people discussing "why monads" it usually degrades into code examples and the OP still left asking "yeah? so? I could already do X? what did that do for me?"
Similar to how a C++ programmer trying to tell a C programmer about std::vector might leave the C programmer is just saying "yeah? so? void* works just fine."
I was attempting to steer the discussion in a different direction: about taking what you know and codifying it, which allows you to be sure - at compile and/or runtime - about what's happening.
To take it back to your original question:
> Can someone give me a practical example of when one would want to use a monad?
Others have given good examples. But, I'll try and put it into the context of my reply by making up a contrived example.
Let's say you have a hash map and want to look up a key's value. The function can return the value stored or a default if the key doesn't exist. But, you can't tell the difference between your default value being returned or the same value already existing.
One solution would be to return multiple values, including a boolean indicating whether or not it's the default. But, presumably (since we care in this contrived example), downstream decisions and further data needs to know if the key was present. So, you need to keep passing along both values all the time. After all, per the original reply - any value derived later from the returned value also belongs to the category of "maybe derived from a default value/missing key".
Instead of constantly passing around the value, a flag, and maybe even the missing key, you could return and pass around a struct of those 3 values.
But, now you have a problem: all the existing functions you want to pass your value to don't understand your struct. Additionally, if you want to remain true to the "truism", those functions need to also return your struct, which they don't.
Monads are the pattern created for solving this exact problem. Monads define an interface for...
1. Taking a value and returning your monad type
2. Taking a function (F) and returning a new function that can take your struct, extract the original value from it, pass it to F, and return a new struct with the return value wrapped as well.
From there, you get all the other benefits people have discussed elsewhere in this thread "for free".
Whether you're working with a strongly typed language like Haskell (and using the compiler to keep you honest) or a dynamic language like Python (and keeping yourself honest at runtime), the problem and pattern holds true.
I intentionally picked a goofy, contrived example to stay clear of all the common examples people usually give (futures, IO, errors, option, etc.) to show how you might have a very different use-case that can still benefit.
* Lists - you don't need to manually for-each over the items, the monad will do the unwrapping for you, reducing boilerplate
* Optional values - you don't need to check for null/no-value, the monad will do that for you and end the computation if an expected value is missing
* State passing - constantly passing a Context type as an argument through your pure functions? Look no further than the State monad, it will do it for you
* Environment/Configuration - don't want to deal with global variables for configuration? Look no further than the Reader monad, it will automagically carry your config to you. This can also be used as a pure dependency-injection system, with none of those hideous DI frameworks and tools.
* Asynchrony - fed up of callback functions, and the boilerplate of dealing with the continuations? Use a promise/task/async monad, it will deal with the sequencing of your operations properly. This is an interesting one because monadic-asynchrony has inspired the async/await systems in C#, JS, and beyond. So, if you've ever used async/await and thought "wow, that was convenient", it's because they're monads.
* Error handling - Exceptions are effectively gotos, why not have something a bit more powerful? The Either monad, Validation monad, etc will handle errors, groups of errors, etc.
* Output aggregation - Want to build some output over the duration of your operation (building a list of strings, generating a document, summing some values, etc.), use the Writer monad to collect output and aggregate it using any available monoid pattern.
* Parsers - Want to declaratively build a parser and not have to worry about error handling, position in the stream, etc? Get the Parsec parser-monad on the case.
* DSLs - making a DSL to capture subsystems in your code-base? Use the Free monad with a sum-type to create a ready-to-go domain-specific language. Simply provide the interpreter.
Want to combinations of all of the above? Many monads can be composed to create a super-monad with the behaviours of both; they're call monad-transformers, and everything "just works".
Ultimately, it's about capturing common patterns and using the same interface to work with the monadic types (in Haskell it's called `do` notation, in C# it's called LINQ). They significantly reduce boilerplate, and allow for very succinct and declarative code.
If you just wanted to open a file, maybe you would write something like this:
run(create_file("filename"))
What if you want to do something with the file? That looks like this:
let create_then_delete = and_then(open_file("filename"), (handle) -> delete_file(handle))
run(create_then_delete)
Functions with a type signature similar to `and_then` turn out to be pretty common, so it's nice to have a way to talk about them. That's basically what monads are for. In OCaml, all functions that have a similar type signature can use the new "let-monadic syntax", which basically lets you rewrite
and_then(open_file("filename"), (handle) -> delete_file(handle))
let\* handle = open_file("filename");
delete_file(handle)
I don't really understand the argument here? Usually we want to properly separate concerns and make sure each thing has one responsibility. Monads are a big help with that.
Any time you have a secondary concern that you don't want to be dealing with explicitly in your straight-through code is a good use case. Any time you would be tempted to use aspect-oriented programming, or a global/thread-local variable, or similar hacks (and IMO they're still hacks when they're built into the language, e.g. exceptions).
E.g. authorization, audit logging, database transactions, error handling - rather than having to use some magical decorator/annotation/macro that breaks all the rules of your language, by using monads you can write code that uses these things as plain old functions working on plain old values, but there's an extensive library of standard operations (e.g. traverse, *M variants of functions like cataM) that you can use to make working with them almost as lightweight as if you were using the magic way.
- http://www.jerf.org/iri/post/2958
- https://philipnilsson.github.io/Badness10k/escaping-hell-wit...
Even in Haskell free monads are used pretty sparingly, so it's definitely not every day defining their own bind or return as data.
I mean, thunks? But yeah, certainly not at the level we usually think of when we talk about defining data in Haskell.
But I can see labeling that an implementation issue. You need to get your dictionary to the right place somehow, and lacking the automatic type-driven threading of type classes I don't know that writing an interpreter for each is the wrong choice. For a lot of monads (reader, state, etc) you want an "interpreter" anyway. It does mean that regular values can't happen to have a relevant monad that you can use to stitch them together in a way that wasn't noticed by the person who created the value.
Imagine that you want to write code that is strictly pure, so that when evaluated, it doesn't do any side effect, it only returns a pure description of the computation it did.
Here's a simple example:
func announce-good-catch(fish)
if(fish.size > 5)
print "We found a big one!
else
print "That one won't even feed a cat, try again!"
You can do this:
func announce-good-catch(fish)
if(fish.size > 5)
return [:print "We found a big one!]
else
return [:print "That one won't even feed a cat, try again!"]
The problem is programming that way is hard, let's add another function:
func get-fish(fish-id)
return new Fish(db.query("select * from fish where id = " + fish-id)
func get-fish(fish-id)
return [:new Fish [:query [:get :db] ["select * from fish where id = " + fish-id]]])
Now combine get-fish and announce-good-catch(fish)?
announce-good-catch((get-fish 10))
[:new Fish
[:query
[:get :db]
["select * from fish where id = 10"]]]
Here is where Monads become really handy, they put all this behind an abstraction that lets you with added syntax sugar feel like your code is written in the impure style, yet under the hood it will convert things to a description of all side-effects and whatever pure behavior is pending the result of those. And it'll let you compose those descriptions together so that from the programmer point of view the code you write looks and feels almost the same as the impure version.
This is the problem Monad solves.
Now once you have that description, eventually you want it to actually run for real so that side-effects and all other described pending behavior gets executed. But what people realized here is you can kind of abuse this a bit, where you could choose to interpret the description in new ways, or manipulate the description prior to executing it. Basically whatever executes the description for real is in charge of how to do that and it could choose to change some of the assumptions like the evaluation order or the thread on which thing execute, etc.
Thus once you have Monads, you can also use them to manipulate evaluation order and semantics.
Now if you don't care about constraining yourself to pure functions, all this can seem like overkill, and it kind of is.
Obviously, people will tell you it's a good idea to make everything pure, because you can more easily test things.
And people will tell you, even if you don't care about the purity, how Monads let you manipulate evaluation order and semantics of the code can be cool and allow for some neat features, so maybe that's something you'd find useful, such as adding tracing throughout automatically, or automatically parallelizing things that don't depend on each other, etc.
This is where some people say that Macros can often be used to similar effect. Because macros, a bit like Monads, operate on the description, macros on the code's AST itself, Monads on the captured Monadic composition. So a macro can also rewrite things to change their evaluation order or semantics.
I wouldn't call myself an expert on all this yet, more of an enthusiast, but that's how I would contextualize it.
The difference here is instead of returning a description of the impure things that should be done, you can make the function pure by returning the list of all possible options.
That means instead of getting a different output non-deterministically for the same input each time the function is called, you now get the same output everytime, which is the list of all possible outputs for that input.
So the context is the same, you want to constrain yourself to pure functions for some reason, so how do you make this pure?
func favorite-color(person-name)
if(person-name.startsWith("A")
return randOf("blue", "green")
else
return randOf("yellow", "black")
randOf("blue", "green")
=> ["blue", "green"]
func generate-favorite-color-string(favorite-color)
return "My favorite color is: " + favorite-color("Abel")
generate-favorite-color-string(favorite-color("Abel"))
bind(favorite-color("Abel"),
generate-favorite-color-string)
And now what the Monad composition will do is it will automatically run generate-favorite-color-string for each element in the list returned by favorite-color and itself will return a list of all those possible results:
["My favorite color is: blue",
"My favorite color is: green"]
1. You are writing a DSL that works with wrapped values.
2. In this DSL you can use arbitrary pure functions from your base language.
3. The value proposition is: those pure functions should not be aware of the fact that they are working with wrapped values, they are written as if they are computing regular non-wrapped values. Bind takes care of this.
4. Indeed the simplest way to implement this is some kind of interpreter. But you don't have to re-implement the entire language inside this interpreter, because of #3