Monads are monoids in the category of endofunctors • Hacker News Board

Re: Monads are monoids in the category of endofunctors

#51

Post by giraj » Fri, Sep 10, 2021, 1:21 AM UTC

jkhdigital wrote: post #18

There’s a few gaps in this explanation that my deductive completionist brain is looking for. Namely, I’m wondering what kind of thing is even capable of being a monoid and an endofunctor at the same time. Mathematically, a monoid is a set (or collection to be more general) closed under a binary operator (the monoidal product) and with a distinguished identity element. An endofunctor is a mapping from a category to it…

You're right, there's a missing step. By "a monoid M in the category C" we mean that M is an object in C along with two morphisms "unit" : 1 -> M and "multiplication" : M x M -> M satisfying the "monoid laws" translated to C. (And really C should be a so-called "monoidal category".) When C = Set, this gives the usual notion of a monoid, which classically is a set by definition, as you say. However there are lots of interesting monoid objects in other categories!

Re: Monads are monoids in the category of endofunctors

#52

Post by brundolf » Fri, Sep 10, 2021, 1:21 AM UTC

epolanski wrote: post #47

brundolf wrote: post #44

Earlier quoted context omitted.

> I wish people understood that fp is much easier to understand by reading definitions. The real landscape of its adoption begs to differ. For the great majority of people, examples and analogies are fantastically more efficient for communicating ideas than building up from first principles. You get to re-use existing mental machinery, intuition, etc, until enough experience has been gained to refine it.

What do you mean?

These concepts are usually explained via first-principles definitions, and they are usually opaque and unapproachable for most people. That's not a coincidence.

Re: Monads are monoids in the category of endofunctors

#53

Post by hikarudo » Fri, Sep 10, 2021, 1:21 AM UTC

zabzonk wrote: post #41

jkhdigital wrote: post #20

Earlier quoted context omitted.

Functors are type constructors, not functions (which map values). But you could be forgiven the misunderstanding, because it is easy to trip over this distinction given the identical syntax. So, to make this absolutely clear, a monad is a type constructor in functional programming. This is why I personally prefer the more “creative” explanations of monads, because they attempt to explain what the monad is doing to th…

> a monad is a type constructor Now explain what a "type constructor" is, otherwise these words are worthless.

A type constructor is something that takes a type and gives you a new type.

For example, in C, if you have any type Foo, the pointer operator * will give you a new type Foo*.

Another example: in Haskell, Maybe is a type constructor, since it takes a type parameter a (Maybe a). So 'Maybe' is a type constructor, but 'Maybe Int' is a type.

So a type constructor is like a function, but it operates on types, not on values.

Re: Monads are monoids in the category of endofunctors

#54

Post by version_five » Fri, Sep 10, 2021, 1:22 AM UTC

pcj-github wrote: post #7

Can't resist: https://www.youtube.com/watch?v=ADqLBc1vFwI&t=1s

Yes, this was unfortunately my first thought too when I saw the headline. The video is really funny though. I don't know how popular a meme it is generally, the first and only time I saw it used was this one wrt functional programming and it still makes me laugh every time I watch it.

Re: Monads are monoids in the category of endofunctors

#55

Post by yodsanklai » Fri, Sep 10, 2021, 1:24 AM UTC

For those who wonder, you don't need to know about category theory to use monads as a programmers.

Re: Monads are monoids in the category of endofunctors

#56

Post by opnitro » Fri, Sep 10, 2021, 1:24 AM UTC

tantalor wrote: post #42

dwohnitmok wrote: post #15

Earlier quoted context omitted.

> a functor is just a pure unary function? No, although a pure unary function could be viewed as a functor, the other direction doesn't hold. The common FP definition of a functor is anything that supports a notion of `map` (subject to the restriction that `map`ping the identity function does nothing, this is why a Functor is slightly more than just a Mappable). This is not a unary function although map takes a unary…

> why a Functor is slightly more than just a Mappable Explain that again?

A Mappable would be anything that has a `map` function. A `Functor` is a something that has a `map` function _AND_ obeys the rule that calling `map` with the identity function produces the same result.

ie: say I have some value `f` that is a functor. If I call `map identity f` I should always get back `f`. The mere existence of a `map` function doesn't imply this law holds.

The identity function always returns it's argument unmodified. (identity x = x)

(Now, in Haskell the type system does not encode that law, but not following it would be breaking the interface.)

If this explanation doesn't make sense or you need more examples I'm happy to expand

EDIT: Both me and grandparent forgot another law for functors. They also need to preserve composition.

fmap (f . g) == fmap f . fmap g

In english, if I combine the functions f and g and map them, it should be the same as if I first map g and then map f

Re: Monads are monoids in the category of endofunctors

#57

Post by catgary » Fri, Sep 10, 2021, 1:24 AM UTC

6nf wrote: post #48

jkhdigital wrote: post #20

Earlier quoted context omitted.

Functors are type constructors, not functions (which map values). But you could be forgiven the misunderstanding, because it is easy to trip over this distinction given the identical syntax. So, to make this absolutely clear, a monad is a type constructor in functional programming. This is why I personally prefer the more “creative” explanations of monads, because they attempt to explain what the monad is doing to th…

>Functors are type constructors So why can't we just call the damn things 'Type constructors'?

Not every type constructor is a functor.

Re: Monads are monoids in the category of endofunctors

#58

Post by edflsafoiewq » Fri, Sep 10, 2021, 1:25 AM UTC

The basic analogy between them is this:

A monoid is something where you take two things and multiply them to get one thing. 2 x 3 = 6

In a monad, you take a doubly-nested thing and "multiply" and get a singly-nested thing: [[a,b],[c]] => [a,b,c]

The monoid laws say that, though you can multiply in different ways, it doesn't matter what order you do it, the end result is the same: (2 x 3) x 4 = 2 x (3 x 4)

The monad laws say the same thing: the order you do the "un-nesting" doesn't matter:

  Inner-most first:
    [ [[a,b],[c]], [[d]] ] => [ [a,b,c], [d] ] => [a,b,c,d]
  Outer-most first:
    [ [[a,b],[c]], [[d]] ] => [ [a,b],[c], [d] ] => [a,b,c,d]

-----

If you take the definition of a monoid, which has stuff like

  M is a type
  multiply : M x M -> M     (multiplies two elements)

what it means to do it "in the category of endofunctors" is it changes into

  M is an endofunctor, a is any type, Ma is M applied to a
  multiply : M(Ma) -> Ma    ("multiplies" doubly-nested element)

and when you do these changes for the whole definition of a monoid, what you get is exactly the definition of a monad.

Re: Monads are monoids in the category of endofunctors

#59

Post by brundolf » Fri, Sep 10, 2021, 1:26 AM UTC

hikarudo wrote: post #53

zabzonk wrote: post #41

Earlier quoted context omitted.

> a monad is a type constructor Now explain what a "type constructor" is, otherwise these words are worthless.

A type constructor is something that takes a type and gives you a new type. For example, in C, if you have any type Foo, the pointer operator * will give you a new type Foo*. Another example: in Haskell, Maybe is a type constructor, since it takes a type parameter a (Maybe a). So 'Maybe' is a type constructor, but 'Maybe Int' is a type. So a type constructor is like a function, but it operates on types, not on values…

So this is a perfect example of how things could be better-explained to the average developer via analogy:

"You can think of a type constructor like a generic type, particularly the way those work in languages like TypeScript"

Edit: The C example was added after my initial comment, and is better than nothing, though I'd tend to say the pointer example is a bit of a weird one to go with. Of course intuitiveness is relative and I'm not saying an example has to mention TypeScript or whatever to be valid. But I do think, like, C++ templates would be a somewhat clearer comparison to make for that audience.

Re: Monads are monoids in the category of endofunctors

#60

Post by 6nf » Fri, Sep 10, 2021, 1:27 AM UTC

JadeNB wrote: post #50

void_mint wrote: post #33

Earlier quoted context omitted.

> The precise terminology is vital; it's how we avoid these errors when talking about this very abstract stuff. Given that the OP is very wrong, precisely because of the kind of attitude you've taken here, I hope you'll take this opportunity to reconsider your views. Your behavior is precisely the behavior that someone new to FP would see and say "Hard pass on that", which goes into the greater problem of FP being un…

> If you cannot communicate with a beginner in language they understand, A.) you don't really understand it either This is true, but the problem is that people will always prefer the explanation that is, as the saying goes, "simple, neat, and wrong" over the explanation that is more complicated, especially if they (and possibly the person explaining) aren't aware that the simplified version is wrong. Even if one star…

You have to start with the 'simplified but not technically perfectly correct' and then add in the nuances to get to the real point. Starting with words like 'functors' that most software engineers today will not be able to define is not useful.