When to pass the category as the first argument

[zickgraf]

With the recent improvements to CompilerForCAP we are approaching a point where we can rely on the type system for resolving operations instead of having to always pass the category as the first argument. This is not on my immediate to-do list (because the current system works very well) but I would like to collect some thoughts for future reference. So the question is: Why resp. in which cases do we want to pass the category as the first argument even if it is not mandated by CompilerForCAP?

Possible answers:

1. Passing the category is the correct approach when thinking type theoretically, especially when more than one category is involved, see https://github.com/homalg-project/CAP_project/issues/643#issuecomment-796805593.
2. In the implementation of doctrine based category constructors, CAP operations might be applied either to the category itself or to the underlying category. Passing the category as the first argument makes this explicit in a single glance, e.g. in https://github.com/homalg-project/CAP_project/blob/0e9ea378fefe8cd61300893ca9d699d467592c3c/FreydCategoriesForCAP/gap/FreydCategory.gi#L1691.
3. In the context of 2. one is forced to think explicitly about which operation should be called for which category. This should help avoid bugs like https://github.com/homalg-project/WrapperCategories/commit/ea144def4e56d8c4abb949f0168e4601f85601f8#diff-33168b5db86a98bd49575646c89f0e53bfcefe5aff39bb3c99209fc7837d8e05L429.
4. In the context of 2., this information could also be used for automatically computing operation weights in doctrine based category constructors from the operation weights of the underlying category. Of course, the required information could also be obtained using the type system, but having the information available in a more immediate manner might have advantages (with regard to better performance, less dependencies, less complexity, etc.).

[mohamed-barakat]

I agree with all points. I am now used to making the category explicit. The only caveat is GAP's limit of bounding the number of arguments of an operation to six, which is pretty annoying (Julia does not have this limitation).

[zickgraf]

Some additional thoughts from a discussion: There are two settings where omitting the category might make the code more readable:

1. In derivations which only deal with a single category.
2. For external operations which are only valid for a certain category anyway (e.g. some helper operations). However, in this case one could also simply use a global function.