Refactor FinitaryCategory Type Class

[jsbezerra]

Refactor the Morphism type class, renaming it to FinitaryCategory to better match its responsabilities.

At the same time, implement @ggazzi's suggestion of using a Context Monad to store important information about the category, such as the type graph of a TGraph and the type graph and NAC strategy of a TSpan.

• Rename Morphism to FinitaryCategory
• Add a "context monad" to the type classes
• Flip the arguments of compose and add an alias (<&>)
  • To do the same thing for Data.Relation ?
• Integrate FindMorphism into FinitaryCategory

[jsbezerra]

This will cause a major API change, so we need to discuss this better.

[jsbezerra]

Question: should we also change the order of paramaters in the compose function to reflect exactly the category operator?

[ggazzi]

In this case it might even make sense to use some sort of operator for morphism composition. Clearly we can't use (.) which is already function composition.

One possibility would be to define an instance of the Semigroup class, so we could use the (<>) operator. I don't think this would fit, though, since some morphisms aren't actually composable so it might violate the laws of the Semigroup class.

Otherwise, we need to find an operator that is not too noisy and doesn't clash with common Haskell libraries.

[jsbezerra]

It makes sense. We could use <&>

https://www.haskell.org/hoogle/?hoogle=%3C%26%3E

[ggazzi]

The name FinitaryCategory would be technically more appropriate than FiniteCategory. A finitary category where each object is finite (i.e. has a finite number of subobjects), but the number of objects may be infinite.

[jsbezerra]

Updated

[ggazzi]

@lm-rodrigues once suggested to me that FindMorphism might be unnecessary, since all instances of Morphism should also implement FindMorphism. I think this is even more true of FinitaryCategory: since the objects are finite, finding morphisms between them is definitely decidable.

How about we integrate FindMorphism into FinitaryCategory?

[jsbezerra]

About the integration of FindMorphism and FinitaryCategory:

What would be the case for the Category Graph, which today only implements FinitaryCategory?

Should we also implement FindMorphism for it (even though we do not use it) or should we leave it unimplemented and raise and error accordingly?

[ggazzi]

Good point. As it stands, I think it would be best to keep these type classes separate, since they do express separate concerns (the "definition" of a finitary category is independent of the algorithms for finding morphisms between its objects).