Open conal opened 3 years ago
@JacquesCarette: As you’ve expressed interest in helping, maybe a good first step would be for you to review Category.Sub
, Category.Homomorphism
, and Cartesian.Sub
and discuss here in this issue. You may have some suggestions for improvements, and the discussion may help see how to approach the cartesian homomorphisms and beyond (including cocartesian, preadditive, and biproduct).
Despite considerable effort, I have not yet succeeded in defining the cartesian or cocartesian counterparts to the composable homomorphism building blocks.
Cartesian.Sub
is the cartesian counterpart toCategory.Sub
, which a variation ofCategories.Category.SubCategory
, refactored to enableSubCat
intersection. (The issue there was sharing an object mappingU
. An earlier attempt added an equality constraint argument to intersection, which was incompatible with a pretty binary infix notation.)Category.Homomorphisms
contains building blocks for theSubCat
inCategory.Sub
. Each building block wraps up the homomorphism property for a single operation (nullary, unary, or binary), to be combined via the intersection and mapping operations defined inCategory.Sub
. [Category.Homomorphisms
] only supports subcategories ofSetoids
, which I consider a weakness.Cartesian.Homomorphisms
is a start on the cartesian counterpart toCategory.Homomorphisms
. I got tangled up in types for the categorical⊤
and_×_
. In all of the uses I anticipate, the categorical⊤
and_×_
will match in the underlying cartesian category (of which we’re forming a subcategory). I tried to state this assumption in theOps
structure inCartesian.Sub
but have been unable to exploit it successfully inCartesian.Homomorphisms
.