Augmenting Arrows

[zenna]

One area which is very cumbersome is attaching XAbVaules with arrows. We basically have to keep passing both around. I realised there are a bunch of hacks that I have implemented to make this slightly easier but they become more difficult the more you nest arrows. I'm thinking about a solution that would break the least things:

• CompArrow should get a new field: tabv::TraceAbValues (This is a little difficult because the type TraceValues depends indirectly on CompArrow and Julia doesn't support pre defining types, but there are some workarounds)

• Augmenting/attaching/conditioning an arrow with a tabv should normally be a purely functional operation to create a new composite arrow that is not equivalent to the first one. This is because (i) an augmented arrow is different function (some elements of the relation are removed), and (ii) so that augmenting an arrow does not modify existing uses of the original CompArrow elsewhere

Things that would need to change:

• add_sub_arr!: If you added an augmented composite arrow to another composite arrow, one technical issue is that you need to update the tabv of the augmented arrow.

• A function to add tabv to a carr

  "Condition `carr` with `tabv``"
  condition(carr::CompArrow, tabv::TraceAbValues) = ...

• Update invert, pgf, (anything else?) to appropriate transfer tabv.

• Perhaps Type should be an tabv as well. Looking at the port properties of a CompArrow: name, type, Direction, and the labels, type is the odd one out. Type inference could be done with normal propagation.

Anything else?

Other points

1. In principle I think you should be able to augment primitive arrows, what's the best way to do this?
2. Terminology: augment/condition/attach?

[zenna]

Clarifying "one technical issue": TraceValues are represented by a source TraceSubPort. That is, all TraceSubPorts in a TraceValue are those that it directly or indirectly connected to the source. But if you put a composite arrow within another arrow, some of the sources might change, so that TraceValues would have to be updated to reflect that.