The Monad Called Free (2014)
blog.sigfpe.com
The Monad Called Free (2014)
1–10 of 44 posts
Re: The Monad Called Free (2014)
#2Today I am a professor in computer science and still draw on it for examples in my advanced functional programming course. Just last week we did the loeb function, as an example of interesting use of Functor.
Loeb function: http://blog.sigfpe.com/2006/11/from-l-theorem-to-spreadsheet...
Re: The Monad Called Free (2014)
#3Re: The Monad Called Free (2014)
#4Free Monads are everywhere. Learning Haskell at this time was such an amazing experience. Haskell has incredible library stability, the kmettoverse feels the same, my is still good enough for most situations, there are new streaming libraries but accomplish the same things as conduit and pipes. LLMs are as decent as you would expect on Haskell, and have helped me debug some situations where I would be fighting GHC us…
Re: The Monad Called Free (2014)
#5Free Monads are everywhere. Learning Haskell at this time was such an amazing experience. Haskell has incredible library stability, the kmettoverse feels the same, my is still good enough for most situations, there are new streaming libraries but accomplish the same things as conduit and pipes. LLMs are as decent as you would expect on Haskell, and have helped me debug some situations where I would be fighting GHC us…
Monads, arrows, applicatives, and functors make the world go round.
Re: The Monad Called Free (2014)
#6I owe so much to this blog! It was such an inspiring read when I started out programming in Haskell back in 2007. Today I am a professor in computer science and still draw on it for examples in my advanced functional programming course. Just last week we did the loeb function, as an example of interesting use of Functor. Loeb function: http://blog.sigfpe.com/2006/11/from-l-theorem-to-spreadsheet...
A classic that everyone should read: http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...
I attended a talk of his at Papers We Love at Strange Loop in 2018, I didn't really read the description and I was vaguely expecting something Haskell related, and instead got this: https://www.youtube.com/watch?v=766obijdpuU
I could barely understand it, but was impressed by what I could grasp. Dan Piponi's range is amazing, dude is brilliant
Re: The Monad Called Free (2014)
#7Earlier quoted context omitted.
Monads, arrows, applicatives, and functors make the world go round.
People think category theory is weird and confusing, but really it just managed to name things (classes) that before were just "things". One might not know what monad or functor is, but they surely used it and have intuition on how it works.
Do you understand "flatmap"? Good, that's literally all a monad is: a flatmappable.
Technically it's also an applicative functor, but at the end of the day, that gives us a few trivial things:
- a constructor (i.e., a way to put something inside your monad, exactly how `[1]` constructs a list out of a natural number)
- map (everyone understands this bc we use them with lists constantly)
- ap, which is basically just "map for things with more than one parameter"
Monads are easy. But when you tell someone "well it's a box and you can unwrap it and modify things with a function that also returns a box, and you unwrap that box take the thing out and put it inside the original box—
No. It is a flatmappable. That's it. Can you flatmap a list? Good. Then you already can use the entirety of monad-specific properties.
When you start talking about Maybe, Either, etc. then you've moved from explaining monads to explaining something else.
It's like saying "classes are easy" and then someone says "yeah well what about InterfaceOrienterMethodContainerArrangeableFilterableClass::filter" that's not a class! That's one method in a specific class. Not knowing it doesn't mean you don't understand classes. It just means you don't have the standard library memorized!
Re: The Monad Called Free (2014)
#8Earlier quoted context omitted.
People think category theory is weird and confusing, but really it just managed to name things (classes) that before were just "things". One might not know what monad or functor is, but they surely used it and have intuition on how it works.
Right. I don't know how many times I've been exasperated by how monads are perceived as difficult. Do you understand "flatmap"? Good, that's literally all a monad is: a flatmappable. Technically it's also an applicative functor, but at the end of the day, that gives us a few trivial things: - a constructor (i.e., a way to put something inside your monad, exactly how `[1]` constructs a list out of a natural number) -…
So then when you look at List, Maybe, Either, et al. it's interesting to see how their conforming to the laws "unpacks" differently with respect to what they each do differently (what's happening to the data in your program), but the laws are just the same.
The reason this was an aha moment for me is that I struggled with wanting to understand a monad as another kind of thing — "I understand what a function is, I understand what objects and primitive values are, but I don't get that List and Maybe and Either are the same kind of thing, they seem like totally different things!"
Re: The Monad Called Free (2014)
#9Re: The Monad Called Free (2014)
#10In addition to the free monad presented in this post, there is a variant, called the "freer" monad, based on the "bind" operation instead of the "join" operation:
data Freer f a where
Pure :: a -> Freer f a
Bind :: f a -> (a -> Freer f b) -> Freer f b
I believe this definition originates from the following paper by Oleg Kiselyov and Hiromi Ishii: https://okmij.org/ftp/Haskell/extensible/more.pdfWhen thinking of monads as giving the semantics of some computational strategy, it's easier to define them in terms of "bind" instead of "join." This way of defining monads is sometimes called a "Kleisli triple" because it is better suggestive of "Kleisli arrows," or functions of the signature `a -> m b`. The "bind" operation defines how to compose a monadic computation with its continuation, and from this perspective, the "freer" monad resembles an abstract syntax tree.
Originally, Eugenio Moggi proposed monads as a technique for specifying the denotational semantics of programming languages. All Java programs "really" happen in the IO + Either monads, because all Java programs may perform IO and throw exceptions. To my understanding, free monads are the monad that OCaml 5 runs in, because they give the semantics for effect handlers (or resumable exceptions).