Nomenclature: How to call the filter `IsMatrixCategory`?

[zickgraf]

I would like to define a canonical name for filters like IsMatrixCategory, IsCategoryOfRows(OverCommutativeRing), IsFreydCategory, IsCategoryOfFiniteSets etc., i.e. for the filters of a usually parametrized category (independent of the concrete parameter). Ideas:

1. We could view them as very special doctrines, but I think this would be confusing.
2. The term CategoryFilter is already occupied by the filter automatically created for a concrete category.
3. ParametrizedCategoryFilter is a bit confusing for unparametrized categories like FinSets.
4. TemplateCategoryFilter?
5. PrototypeCategoryFilter? (as in prototype-based programming)
6. CategoryClassFilter? (as in OOP)
7. CategoryFrameFilter? (as in "framework")
8. CategoryBlueprintFilter?
9. CategoryScaffoldFilter?
10. CategoryDraftFilter?

Ideas are welcome :-)

[zickgraf]

Addendum: The name should also canonically extend to the object and morphism filters, e.g. TemplateCategoryObjectFilter.

[kamalsaleh]

Because they are intended just for internal usage, I would rename the current CategoryFilter, ObjectFilter and MorphismFilter into InternalCategoryFilter, InternalObjectFilter and InternalMorphismFilter. After that your TemplateCategoryFilter becomes CategoryFilter, etc.

[zickgraf]

I have thought more about what we actually require when using those filters, e.g. IsCategoryOfRows. From grepping through the code, we certainly require a corresponding mathematical concept (including e.g. the choice of a monoidal structure) and a certain data structure (e.g. when something lies in IsCategoryOfRows, we expect its objects to be GAP objects with a non-negative integer stored in the attribute RankOfObject with the usual mathematical interpretation). I assume that traditionally people also associated a certain concrete implementation with each filter, because we only had a single implementation for e.g. categories of rows.

If we would only require the mathematical concept, IsCategoryOfRows and IsAdditiveClosureOfRingAsCategory would be equivalent. However, due to different data structures they are not, so we certainly want to distinguish between the two.

Since the advent of the compiler and wrapper categories, we potentially have multiple implementations of the same kind of category, e.g. IsCategoryOfRows in the traditional sense and IsCategoryOfRowsAsAdditiveClosureOfRingAsCategory. Those new implementations might behave exactly as the original ones, but they might also differ if one can make choices in the implementation (e.g. choose a different lift in cases where there is no unique one). In the latter case, one can use IsCategoryOfRowsAsAdditiveClosureOfRingAsCategory instead of IsCategoryOfRows as long as one only relies on mathematical properties. However, one must not mix computations between the two because the implementations might not be compatible. (For a real life example of all this see LeftPresentationsAsFreydCategoryOfCategoryOfRows: This explicitly has the filter IsCategoryOfLeftPresentations but differs in the implementation of the monoidal structure.)

So the question is: Should we distinguish between IsCategoryOfRows and IsCategoryOfRowsAsAdditiveClosureOfRingAsCategory or not? In the context of CompilerForCAP I would say that we do not want to distinguish between the two. But even without the compiler the question is important: do we want to be able to change non-mathematical implementation details (like the result of a lift with choices for performance reasons) without notice or would we call this an incompatible change?