Guilherme Grochau Azzi

Although the workaround is very simple, the tokenizer needs minimal changes to handle these comments. Since the fix is so simple, I believe it is worth it.

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...

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...

@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...

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...

Why are there multiple functions `findAllDeleteUse`, `findAllProduceForbid`, etc, instead of just one `findAllConflicts` whose result can be filtered as required?

Regarding `nacDownwardShift`, couldn't we frame it as shifting a _constraint_ rather than an application condition? After all, an application condition is essentially a constraint whose "antecedent-object" is the left-hand side...

Regarding the match restriction and NAC satisfaction, this will interact with a complexity of symbolic graphs: we don't want to restrict matches to be completely monic, just monic on the...

This should be addressed with issue #25

### Proposal for blank lines Two blank lines between different sections of the source code. One blank line between top-level definitions. A blank line may be used between functions in...