Dirty CompArrow after updating inner CompArrow

[zenna]

If you add a port to a CompArrow and it is referenced by a SubArrow within one or more other CompArrows, (even itself) they may be dirty in that

• If you remove ports, all those edges will be invalid
• If you change the types of ports; something that is type consistent may become type inconsistent
• If there are new ports, then there will not be corresponding vertices in its parents edges (is this still true if it is a self, parent?)

This makes the currently way to do invert for example, problematic

[zenna]

This problem was avoided in invert because it replaces the arrow with replace_sub_arr! which adds the necessary things

[zenna]

Could alternatively, in outer, iterate through subarrows again and update parent with new edges accordingly

[zenna]

Alternatively have a function which cleans a composite arrow by removing broken links, adding necessary ports.

• Might be a useful function in general
• But would probably incur doing extra unnecessary work in this case
• Not all things can be cleaned properly, will lead to arbitrary rules (e.g. if we src(sprt) but !should_src, how to clean? Delete the edge? Reverse it?

It might then be better to decompose this into a set of different cleaning regimines, e.g. one which reverses bad edges, one which removes broken links, and the apply the necessary cleans.

[zenna]

Keep parents updated by construction

Pros:

• If possible it would be nice because a CompArrow might be used in multiple different places.
• But somehow I would need to update the necessary light graphs; so this is not possible in the current model
• And even if I eschew light graphs, and for example only stored pairs of (SubArrow, PortId) => (SubArrow, PortId), if I added a new port I wouldn't have to update a parent perhaps, but if I deleted one then it would still be dirty.

I can't see any way around having to update parents fundamentally, short of storing one single large graph for everything, which would probably be more problematic in many more ways.

For these transforms, invert, and pgf, etc I am really constructing a new arrow; I just happen to be doing it in this mutative way. So I think it's fine that a parent is invalid if I've changed it's child.

On the other hand suppose I have a parametric inverse with redundant parameters, and I figure out a simplification. I don't want to have to fix all the parent subarrows