more on category theory - especially monad

[razcore-art]

Just gonna open up an issues before I forget.

It's a tricky subject because you have explain a lot of stuff before, but I think it might be doable. Especially on Monads where there's this mystery - people just have a hard time getting it. And at least in my case I can explain why and it's possibly others have the same problem.

So when I first learned about functional programming one of my first books was learn you a haskell for great good which is fine, but until you get to Monads you do very little and when you get to it it's explained in terms of these functions that relate to the do notation, kind of like what you're doing here, but I think here it's explained better.

One major reason I couldn't understand them is because my brain works by putting together pieces and I need to understand the underlying principle. And the principle isn't in how the typeclass functions work or even the laws. It's in how the Category Theory (CT) concept of the Monad is translated to programming. This video finally made me understand: https://www.youtube.com/watch?v=gHiyzctYqZ0. So the way to introduce Monads from ground-up, I think, is to explain first the composition rules in CT and explain how one can deal with composing functions (Kleisli Arrows) that return a boxed thing (Functors) instead of just the thing. And bind is just a by-product, or better yet a helper function to implement this composition (>=> - fish operator) since it's easier to implement than the fish operator.

Don't know if you wanna go down the rabbit hole, I'm just gonna leave it here for you to review the idea :)

[JordanMartinez]

I'll look into it. I explain Monads in the way that I understand them by using a Box-like type. However, I later saw that Kleisli arrows are what understanding the Monad laws more sensible.

Thanks for linking to the video.

[JordanMartinez]

Just wanted to give you an update. I watched through the video and it made a lot of sense due to how he presented it. However, I think I also found his initial starting point (kleisli arrows) confusing, probably because this is the later video where a prior one helps us see the need for kleisli arrows, haha! So, I think I'll need to watch that one before it all clicks.

Also, I've already linked to this videos in Ecosystem, but it might be wiser to put that in the Philosophical Foundations for FP folder since I've found there's a lot more behind simple ideas like Sum/Product types than just Either/Tuple.

Still, I think it should appear before my "bind-based" explanation because my explanation does not cover why join or >=> exists in the first place.

[razcore-art]

Yes, you do need to know what kleisli arrows are, but once you see they're really no big deal (to understand and explain) I think explaining the monad through the arrow composition is really important to getting the full idea behind it. And this explains easily the >=> fish operator (composition) and join then

Kleisli arrows are just arrows that return a functor/monad object instead of an object in the same category, so instead of a -> b you have a -> f b, that's it :). And the rest follows naturally when you ask the question: how can I compose arrows of the type a -> f b? because they expect a as input not f a.

[JordanMartinez]

Makes sense. pure is basically the simplest kleisli arrow then.

[JordanMartinez]

@razcore-art Reading through this definition of Functors, I'd say that type classes are really only understood when one uses the appropriate CT terms and definitions before 'translating' them into how they are defined in PureScript/Haskell. There's just too much information that gets lost when one doesn't explain their context. However, learning about that context only becomes desirable when one realizes the power of CT concepts and how their current understanding is lacking insight that spans broader than their current one.

[razcore-art]

Although I've talked with few people that didn't learn anything CT related and can still do type level programming quite successfully and that requires a good understanding of type classes (justinwoo is one of them), there might be people that don't fully understand FP without CT. I'm one of them, I need to understand why stuff happens in order to get the point. That's why I had a hard time with monads before seeing video I linked. So it's debatable if CT is really needed in general, for understanding how stuff work it's key, but for using FP I don't necessarily think it's required.

[JordanMartinez]

Mm.... Good point. I agree that I don't think one needs to know it to write FP, but I think one can approach problems from a much more informed position if they do know it.

Getting back to the issue at hand, perhaps there should be a "Advanced Content" section for each type class that explains things in a more advanced manner or links to other explanations that a beginner should likely avoid at first?

[JordanMartinez]

@razcore-art I thought you might be interested in this conversation:
https://discourse.purescript.org/t/main-ideas-diagrams-of-category-theory-part-1-videos-1-1-to-3-1/567/11

[razcore-art]

Nice, thanks for the notice, I'll be in there :)