Confused by terminology
erlandsona opened this issue · comments
Reading DaoFP and around CH8 the term "Stick Figure Category" was introduced but not defined.
Maybe it's implied what a stick figure category is but I'm definitely confused.
Also w/ respect to my general ability to follow along, I was doing fine with everything up till CH8, not because I don't understand functors but because I don't understand how the category theory notation maps to Haskell.
Not sure if it's reasonable or helpful to ask for things like [C,D](F,G) to be translated into Haskell notation but I got very lost right around there.
Then CH9 builds on some of the concepts in previous chapters but I don't have a Math / Set Theory background so these are just new terms to me and there seems to be an implication that I should already know what a limit/co-limit is.
At this point I'm just suspending my disbelief but I've lost traction w/ respect to my ability to follow along with what knowledge I have from Haskell concepts.
It's still work in progress, so any feedback is welcome. It's not always easy to keep track of what I have defined, and what I though I have defined. I'll look into it and try to clarify.
I'm adding an explanation of stick-figures as "categories with a small handful of objects and arrows."
Not all concepts of category theory map into haskell. In particular the functor category is built "on top" of Haskell.
I'm not sure what math/set theory concepts are causing you problems. I tried to stick to the description of sets as things having elements. I don't expect the reader to be familiar with limits.
I might add that I don't expect a reader to assimilate all this knowledge on first reading (certainly I wasn't able to do that, when I first started reading math books). I usually sit with a pencil and paper and work through difficult concepts until I understand them.
This all makes a lot of sense and thank you for the thoughtful response!
Category Theory built on top of Haskell makes sense why the literal Haskell diagrams drop off a bit then...
not sure what math/set theory concepts are causing you problems.
Coming from Haskell I'm familiar with the Haskell definitions for eg: optics / Lenses / Isomorphism, Functor (Bi, Pro, Contra but not their CT diagrams). I know there's a "Co" for most things in CT where the arrows are flipped but still not super clear on how to apply some of the co objects or where they emerge in certain things.
CH9: brings up terms I hadn't heard of before (leaving out the "co" counterparts for brevity)
- Whiskering, spans, cones, presheaves, limits, ends, etc...
And I think I just got lost because these were all defined in terms of their CT diagrams and not Haskell syntax.
I don't expect the reader to be familiar with limits.
I don't expect a reader to assimilate all this knowledge on first reading
Which means I'm reading it with the right posture then... which is to say, take in the fire hose and let it all absorb later 😅
I usually sit with a pencil and paper and work through difficult concepts until I understand them.
This is the part I don't have quite the discipline for, meaning, I wouldn't know how to check my work? Whether or not I'm just drawing random squiggly lines that turn into doodles or if the diagram I'm working through actually works for some definition. Which in part was why I was excited about the connection of these things directly into Haskell because they can be verified by the compiler.
Well at least for the subset of things that can be modeled in Haskell.
Which I suppose gives rise to another question, which languages CAN model the concepts Haskell can't?
Idris/Agda/Coq? Or are there concepts that even they can't model properly?
Do I just need to bite the bullet and dig into one of them?
Yes, all three languages can model these concepts, but the translation is not easy. The problem is that many things in CT are defined using commuting diagrams, and these involve equalities of arrows, and equalities cannot be expressed in Haskell.
and these involve equalities of arrows, and equalities cannot be expressed in Haskell.
I thought QuickCheck could be used in a way to prove some of the equalities... wait.
Equality of Arrows like you can't do id == id in Haskell ah, yup okay I that makes sense.
Well or like Golden Tests could be used to prove things like Isomorphisms but I suppose that's only a subset and it'd be WAY nicer if we could express equality of arrows directly.
But then of course maybe it's not practical/commonplace to use Dep-typed languages in production code?
Well in any case, thanks again for your response. I'm onto CH10 now and it's making more sense again weirdly enough. 😅