Hacker News Reader

Comment by oblio | Hacker News Reader

I'm still kind of having problems with monads. Funnily enough, I recently found an article explaining what monoids are: https://fsharpforfunandprofit.com/posts/monoids-without-tear...

    You start with a bunch of things, and some way of combining them two at a time.

    Rule 1 (Closure): The result of combining two things is always another one of the things.

    Rule 2 (Associativity): When combining more than two things, which pairwise combination you do first doesn't matter.

    Rule 3 (Identity element): There is a special thing called "zero" such that when you combine any thing with "zero" you get the original thing back.


    With these rules in place, we can come back to the definition of a monoid. A "monoid" is just a system that obeys all three rules. Simple!

Long explanation overall in the article, but based on 6th grade math. I understood it, and it stuck. Could someone extend the monad explanation from here? Maybe I'll finally get it :)

View on HN

This was way more difficult than I thought and still doesn't look right. But at least I get to strike write a monad tutorial off of the bucket list.

  You start with a bunch of transformations that either turn a thing into a (different) *useful* thing or into a *dead end*.
  
  Rule 1 (Left Identity): Applying a transformation to a useful thing is the same as simply transforming a plain thing.
  
  Rule 2 (Right Identity): A transformation that merely makes a thing useful has no effect when applied. Useful things stay the same, dead ends stay dead.
  
  Rule 3 (Associativity): You can merge any two transformations into one, which behaves the same as if you applied the first transformation to something and then applied the second transformation to the result.

Start with a functor--a parameterized type with fmap. Maybe t, Either e t, [t], IO t, State s t, and so on.

Consider a monad m and a function, a -> m b. Frequently you want to feed another monadic value, m a, into that function.

A monad gives you a function, >>=, that lets you take m a and feed it into a -> m b.

So any function that does IO, that looks like a -> IO b, you can take an IO a and plug it into a -> IO b. Any function that manipulates a state, you can take State a and plug it into a -> State b. This is the heart of a monad: gluing monadic functions together.

The meaning of >>= depends on the monad you're in. You also need return :: a -> m a, which can take a thing and put it in a monadic value.

There are monad laws also. A lot of times there's several ways to manipulate monads to do something, and the laws are needed to make sure they're all equivalent. For everyday monad use the laws aren't terribly important to remember, and GHC's linter will helpfully point out when you can use them.

That's my attempt at a short explanation. The "monad tutorial problem" has been weighing on my mind. The only way I ever understood monads was by reading and rereading the definition and examples. Tutorials never taught me anything.

I'm still slightly confused. The author suggests that a monad is composed of 3 functions. It seems to me you've shown 2 of these functions.

a -> m b

>>=

What is the third function? Did I misunderstand you?

The author is mistaken. There are only two functions necessary for a monad: >>= and return

Also, the type of return is `a -> m a`. The type you cite `a -> m b` is a parameter to >>= (which has type `m a -> (a -> m b) -> m b.

The author might be refering to a quirk of the Haskell monad interface, which has to additional functions:

">>" which can be easily defined in terms of >>=. I assume this is part of the interface so users can override it with a more efficient implementation, but every implementation I have seen just uses the default one.

"fail" which is an error handler. This is being depreciated as a function of Monads, and moved into its own MonadFail typeclass. This also has a default implementation that just throws an exception.

> The author is mistaken. There are only two functions necessary for a monad: >>= and return

Probably because monads are frequently described as triples -- two functions and a functor. The author seems to have reduced that to three functions (presumably fmap) without realizing that it isn't sufficient.

I suspect the third function is the one for running the monad. It's different for each one, so it's not part of the type class, but you do need it to use a given monad. (Except IO, though even it has unsafePerformIO)

What is the function for running Maybe, or List?

You're probably over-thinking this. Monad is not a difficult concept, but it is very abstract. Because of that, it's hard to say specifically that "this" is what Monad "does."

Also, monad and monoid are orthogonal ideas in Haskell. Monad doesn't follow from monoid.

Personally, I would just think of Monad as "thing with bind & return." Basically all of the magic of any Monad happens in its bind function. What makes Monad interesting (imo) is that for any type that can be a Monad there are typically only one or two possible implementations of bind that fulfill the Monad laws.

I guess my advice would be to put getting an intuition for Monad on hold. The reason being that most Monads behave very differently from each other (this is a testament to the power of the concept, that it can tie together so many seemingly unrelated ideas.) Just read a bunch of Monad implementations and verify that they fulfill the laws (make sure to also have the typeclass definition in the back of your head.)

To get you started, I recommend you wrap your head around the Maybe, Either e, State, Reader and Writer monads in that order. Unfortunately, you won't be able to look at Haskell source to read these Monads, as their implementations now all use Monad Transformers if I'm not mistaken. You should still be able to find straightforward implementations of these Monads floating around in internet tutorials.

Also, if you intend to have a serious go at Haskell, I recommend the NICTA course as a no-bullshit approach. (Warning: not for the faint of heart. Especially if you're going it alone.)

https://github.com/tonymorris/course

That's a good explanation of Monoids. You can also watch (at least the first half) of this video for more on Monoids:

https://www.youtube.com/watch?v=WsA7GtUQeB8

There are already a good number of people trying to explain Monads in this thread, so I won't attempt it. But I'll say this (in the context of Haskell):

In Haskell, like how Monoid is a typeclass, Monad is just another typeclass. So me mentioning "typeclass" twice in a sentence suggests that you probably have to first understand typeclasses and data types.

Also, I wouldn't recommend tackling Monad right after grasping Monoid. I'd recommend you read about and understand Functor and Applicative functors first, and that will ease you into understanding Monads and actually why you would want to have them.

So, you may want to read these pages from Wikibooks in this order:

https://en.wikibooks.org/wiki/Haskell/Classes_and_types

https://en.wikibooks.org/wiki/Haskell/The_Functor_class

https://en.wikibooks.org/wiki/Haskell/Applicative_functors

https://en.wikibooks.org/wiki/Haskell/Applicative_prologue

The last link is the first section of a chapter on Monads; so use the links on the sidebar to read the subsequent sections of the chapter.

Typeclassopedia is another great resource for the typeclasses I mentioned: https://wiki.haskell.org/Typeclassopedia

It's misleading though because the one sentence definition is actually describing a semigroup. A monoid also has an identity.

Shorter explanation: Monoids are things you can concatenate together.

That's in the same way that (as the article says) monads are things you can bind together (in Haskell, binding will tell how code flows, so monads in Haskell are things with a defined kind of code flow between them), and functors are things you can map over.

A list is all three.

Reply on news.ycombinator.com