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

Re: Monads are monoids in the category of endofunctors

#221

Post by rofrol » Fri, Sep 10, 2021, 7:23 PM UTC

belter wrote: post #206

lmm wrote: post #24

This post is very wrong. Being a monoid in the category of endofunctors means something very different from being a monoid in the normal sense (they're related in a category-theoretic way, but the similarity is at a very abstract level). Simple sequences have a lot of structure which mean they are a lot of different things; it is true that sequences are all of monads, functors, and monoids, but the latter structure i…

The article is just proving what we all know for a long time about Monads: https://twitter.com/randyshoup/status/992773186239516677?lan...

Goodstein: Why spin one-half particles obey Fermi-Dirac statistics?

Feynman: I'll prepare a freshman lecture on it.

He came back a few days later to say: I couldn't reduce it to the freshman level. That means we don't really understand it. https://www.quora.com/What-did-Richard-Feynman-mean-when-he-...

Re: Monads are monoids in the category of endofunctors

#222

Post by edflsafoiewq » Fri, Sep 10, 2021, 7:43 PM UTC

deepsun wrote: post #219

edflsafoiewq wrote: post #210

Earlier quoted context omitted.

Yes, but its usually obvious which one is meant, so you don't bother saying under what operation. Option is a monad under the same concatenation as Array, just think of them as arrays that always have length 0 or 1.

How to concatenate Option-s? Btw your comment seems to contradict another sibling comment.

Like I said, view them as an array with 0 or 1 element and do it just like for arrays. There are only three possibilities:

  [] => []
  [[]] => []
  [[a]] => [a]

Re: Monads are monoids in the category of endofunctors

#223

Post by edflsafoiewq » Fri, Sep 10, 2021, 7:52 PM UTC

lkitching wrote: post #211

deepsun wrote: post #208

So we cannot talk about a type being monad without also saying under what function? E.g. Arrays are monads under concatenation. So why people then say easily "Option type is monad" without stating under which operation? I assume Option is monad under "all" and "any" function, but not sure.

A monad is a triple: 1. A type constructor M of a single argument 2. A function of type a -> M a 3. A function of type M (M a) -> M a subject to the monad laws. So the 'array monad' is the triple (Array, \x -> [x], Array.concat) and the 'option monad' is the triple (Option, \x -> Some(x), \x -> match x | Some(o) => o; None => None). Saying a type 'is' a monad is imprecise but just means it has an associated monad ins…

> I've never seen a type with multiple monad instances but I don't know if there could be one.

There can, it's just like there can two monoid structures on the same set. In fact if you have an example of a set S which has two monoid structures, you have an example of a functor with two monad structures: _ × S. join multiplies the two elements of S, so you get a different monad structure for every monoid structure on S.

Re: Monads are monoids in the category of endofunctors

#224

Post by kaba0 » Fri, Sep 10, 2021, 7:54 PM UTC

void_mint wrote: post #220

kaba0 wrote: post #162

Earlier quoted context omitted.

You don’t have to understand category theory to program in FP languages. But if we want to talk about the mathematical basis, you do need a common vocabulary at least to be able to communicate at all. You could not really explain JIT compilation to someone not knowing anything about computers, could you?

> You could not really explain JIT compilation to someone not knowing anything about computers, could you? You can't explain the concept of doing something only when you absolutely need to, to someone that doesn't know about computers?

If such a “definition” is sufficient, than I’m a rocket engineer as well because the rocket goes brr to the space..

I mean, it may as well refer to eagerness, which is something completely different from JIT compilation. You didn’t even say anything about what the compilation is about (which again, requires some knowledge on computers), nor about the reason for doing that.

Re: Monads are monoids in the category of endofunctors

#225

Post by void_mint » Fri, Sep 10, 2021, 8:37 PM UTC

kaba0 wrote: post #224

void_mint wrote: post #220

Earlier quoted context omitted.

> You could not really explain JIT compilation to someone not knowing anything about computers, could you? You can't explain the concept of doing something only when you absolutely need to, to someone that doesn't know about computers?

If such a “definition” is sufficient, than I’m a rocket engineer as well because the rocket goes brr to the space.. I mean, it may as well refer to eagerness, which is something completely different from JIT compilation. You didn’t even say anything about what the compilation is about (which again, requires some knowledge on computers), nor about the reason for doing that.

Do you provide concrete "definitions" to people that don't/wouldn't understand? How would you handle a child asking you about something beyond their years? Would you just respond with a textbook definition and say "lol sucks to suck"? No, you'd use language they could understand, and you'd guide them as that language increased. This is the difference between "teaching" and "just saying things to sound smart".

It's actually insane how hard programmers want to gatekeep even basic concepts.

Re: Monads are monoids in the category of endofunctors

#226

Post by IndexPointer » Fri, Sep 10, 2021, 9:49 PM UTC

dwohnitmok wrote: post #27

This article is playing fast and loose and I think gives a false understanding of what functors and monads are. In particular there is an unwarranted leap here. If `numToStr` is a functor, then `addOne` (the function that just adds one to an integer) should be an endofunctor. So what's the monad? Yet all of a sudden the article jumps to talking about `Array` as an endofunctor! Which is most definitely not a function…

Yeah, it's very confusing.

Array is a monad. Then what's the function that takes an array and returns another? Is it map? That can't be because map takes two parameters, not one: the array and a function that it will apply to every element. Something is missing in the explanation.

And why is Option a monad? What's the associative function that takes two options and returns another Option?

Re: Monads are monoids in the category of endofunctors

#227

Post by light_hue_1 » Fri, Sep 10, 2021, 10:22 PM UTC

IndexPointer wrote: post #226

dwohnitmok wrote: post #27

This article is playing fast and loose and I think gives a false understanding of what functors and monads are. In particular there is an unwarranted leap here. If `numToStr` is a functor, then `addOne` (the function that just adds one to an integer) should be an endofunctor. So what's the monad? Yet all of a sudden the article jumps to talking about `Array` as an endofunctor! Which is most definitely not a function…

Yeah, it's very confusing. Array is a monad. Then what's the function that takes an array and returns another? Is it map? That can't be because map takes two parameters, not one: the array and a function that it will apply to every element. Something is missing in the explanation. And why is Option a monad? What's the associative function that takes two options and returns another Option?

Leaving the confusing article aside.

Practically, the additional function that monads support is usually called bind and looks like: Array a -> (a -> Array b) -> Array b

This is different from map which is: Array a -> (a -> b) -> Array b

Notice how in map, your function returns a value that isn't lifted in the monad. The bottom one is a functor, the top one is a monad. Functors let you visit an array at every element. Monads let you visit an array and produce a new array each time and they internally decide how they will recombine those values.

This is a bit silly for Array, you just concatenate the outputs. But is more interesting for Option.

map for Option looks like: Option a -> (a -> b) -> Option b

It says "If there's anything in my Option, apply this function to it, otherwise there's still nothing there"

bind for Option looks like: Option a -> (a -> Option b) -> Option b

It says "If there's anything in my Option, run this computation. This computation can also return an option". In this sense, it lets you string together computations that each produce optional values. The whole computation will fail if any part fails. Something that is very useful!

Re: Monads are monoids in the category of endofunctors

#228

Post by IndexPointer » Sat, Sep 11, 2021, 12:13 AM UTC

light_hue_1 wrote: post #227

IndexPointer wrote: post #226

Earlier quoted context omitted.

Yeah, it's very confusing. Array is a monad. Then what's the function that takes an array and returns another? Is it map? That can't be because map takes two parameters, not one: the array and a function that it will apply to every element. Something is missing in the explanation. And why is Option a monad? What's the associative function that takes two options and returns another Option?

Leaving the confusing article aside. Practically, the additional function that monads support is usually called bind and looks like: Array a -> (a -> Array b) -> Array b This is different from map which is: Array a -> (a -> b) -> Array b Notice how in map, your function returns a value that isn't lifted in the monad. The bottom one is a functor, the top one is a monad. Functors let you visit an array at every element…

Thanks for the explanation! The Option example makes perfect sense.

Re: Monads are monoids in the category of endofunctors

#229

Post by opnitro » Sat, Sep 11, 2021, 3:54 AM UTC

tantalor wrote: post #216

opnitro wrote: post #212

Earlier quoted context omitted.

To be honest with you, you're right in that you usually get that one without trying. Most of the things we think of as mappable obey the identity rules.

I think the confusion is calling anything that doesn't "obey the rules" a map function just because it is named "map". For example, ruby's hash "map" returns an array instead of hash. That's not really a map, is it? Making this useless distinction between "things with map function" and "functors" serves no purpose. It should be "things with real/fake map functions". The name of the function does not matter!

Sure, the name doesn't matter. The type does though. `Functor f => a -> b -> f a -> f b` And it most type systems the law can't easily be captured in the type system.

Re: Monads are monoids in the category of endofunctors

#230

Post by kaba0 » Sat, Sep 11, 2021, 5:39 AM UTC

void_mint wrote: post #225

kaba0 wrote: post #224

Earlier quoted context omitted.

If such a “definition” is sufficient, than I’m a rocket engineer as well because the rocket goes brr to the space.. I mean, it may as well refer to eagerness, which is something completely different from JIT compilation. You didn’t even say anything about what the compilation is about (which again, requires some knowledge on computers), nor about the reason for doing that.

Do you provide concrete "definitions" to people that don't/wouldn't understand? How would you handle a child asking you about something beyond their years? Would you just respond with a textbook definition and say "lol sucks to suck"? No, you'd use language they could understand, and you'd guide them as that language increased. This is the difference between "teaching" and "just saying things to sound smart". It's ac…

Well, no matter what you won’t be explaining multivariable calculus to a children. Concepts build on each other and for certain ones, you do have to build from something. You can start teaching math, and indeed for certain topics, taking shortcuts is allowable. But this is context-dependent and not universally true.

Like, you can talk about programming to a child, but still not about JIT compilation.