3 ms·

Mmm, yeah on reading the paper more closely it seems like they don't make essential use of the concept really. It's more of a descriptor of the mechanics of the

Mmm, yeah on reading the paper more closely it seems like they don't make essential use of the concept really. It's more of a descriptor of the mechanics of their combinator language. Personally I'm fine with that - I have no issue with CS people borrowing terminology from category theory to describe stuff, so long as the analogy is reasonable. But I get where you're coming from - having learned some CT in (grad) school, I used to find Haskell wikis confusing as heck because they use CT terminology but nobody clarifies what category they're actually working in!

tome 2y ago
> I used to find Haskell wikis confusing as heck because they use CT terminology but nobody clarifies what category they're actually working in! "Hask", the (almost) category where the objects are types and the morphisms from A to B is the type A -> B.
- bubblyworld 2y ago
  Thanks, I know that now, but it's the "almost" part that trips up people like me! And it's not helped by the fact that the same sources will say something like "a monad is a monoid in the category of endofunctors", yet if you take Hask seriously there should be a discussion of endofunctors on Hask etc. When details are missing my brain gets stuck on figuring them out (whereas for Haskell the right approach is to take it with a pinch of salt and move on I think). Edit: to be more specific, you need to specify what constitutes a type - all possible ADTs under all possible names? Are equivalent functions considered the same morphism? What about seq? Is there a privileged "IO" type, and if not how is it represented in the set of types? What about other monads hiding different side effects? What about bottom? Many of these choices will of course be equivalent in some sense, but technically speaking you don't have a category until you've nailed this stuff down.

tome 2y ago

> I used to find Haskell wikis confusing as heck because they use CT terminology but nobody clarifies what category they're actually working in! "Hask", the (almost) category where the objects are types and the morphisms from A to B is the type A -> B.

bubblyworld 2y ago
Thanks, I know that now, but it's the "almost" part that trips up people like me! And it's not helped by the fact that the same sources will say something like "a monad is a monoid in the category of endofunctors", yet if you take Hask seriously there should be a discussion of endofunctors on Hask etc. When details are missing my brain gets stuck on figuring them out (whereas for Haskell the right approach is to take it with a pinch of salt and move on I think). Edit: to be more specific, you need to specify what constitutes a type - all possible ADTs under all possible names? Are equivalent functions considered the same morphism? What about seq? Is there a privileged "IO" type, and if not how is it represented in the set of types? What about other monads hiding different side effects? What about bottom? Many of these choices will of course be equivalent in some sense, but technically speaking you don't have a category until you've nailed this stuff down.