Fabian Zickgraf

This PR is difficult to review because it introduces so many rules at once, so it's difficult to see how the new compiled code exactly comes from the old code....

Depends :D If only view commits need further discussions, one PR is fine. If we would create too many threads, I would suggest splitting the PR. We can try with...

The first few commits only affect `MorphismFromFiberProductToSink` etc., which I consider niche applications. I'm a bit reluctant specializing too much for such special applications and thus slow down the whole...

Thinking more about this, I do not understand why the `PreComposeList`-PR should change any compiled code (except the one of `PreComposeList` of course). I don't think the additional source and...

Did you give this a try? I don't expect this to work, i.e. I expect that things will simply break later on.

The reason why I chose to generate the colimit operations from the limit operations in https://github.com/homalg-project/CAP_project/pull/1468 was that limits seem to usually come first in CAP, so I expected their...

As far as I can tell, nothing significant is blocking this, see https://github.com/zickgraf/CAP_project/tree/opposite_derivations for a demo. One has to: 1. Make `Opposite` applicable twice (see the commented line on the...

This would also fix #917.

For CAP this is done in https://github.com/homalg-project/CAP_project/pull/1468. The system could easily be extended to more cases (e.g. include derivations including multiple categories), final derivations, and other packages.

@sebastianpos Thanks for the fast reply! I'm planning to automatically dualize derivations as an application of CompilerForCAP, and since the derivations around `CanonicalIdentificationFromCoimageToImageObject` are not symmetric with regard to dualization,...