Don't link all ports to parent

[zenna]

Currently, when we parametrically invert a function we attacH its parametric inputs to its parent (using link_to_parent). Similarly when we compute domain_errors we attach error outputs to the parent.

This means we have a lot of links projecting from each nested composite arrow all the way out to its outermost parent. On the one hand this may seem necessary because we need all the parametric inputs to execute the function for example. On the other hand it is bad for modularity because

• Suppose I discover redundant parameters, if I "fix" an inner composite arrow, I need to update every other composite arrow that it is a parent of
• If I decide I want to fix a parametric input to be constant I need to update all the parent compositions

An alternative approach is to link to not link any port to its parent; the ports of an arrow are specified implicitly as the ports on some of the SubArrows. I believe I initially tried this idea and realised it's problematic because:

• You can't reuse inports without a dupl
• You can't have shortcut connections directly from in_port to out_port without plugging an identity function in htere
• You can't specify the types of an arrow without its contents
• It forces you to conflate implementation with specification

So I think it's a bad idea.

But perhaps there is a middle ground

[zenna]

This problem has become apparent again when solving a parametric inverse. I may find that a parametric inverse has redundant parameters, but eliminating would require me to update all the parents.

• To use a parametric inverse I am going to still want to be able to evaluate the function with parameters of my choice
• One kind of mental model is that an arrow is like a circuit where rather than there being wires between ports, each port receives and projects on a frequency. Typically a projection is restricted to the encapsulating composition but that is not necessarily true.

Changes

• Allow sources (or perhaps all ports) to have a scope
• Derive loose sub_ports
• Figure out complications for recursive ports
• Allow compilation to functions to take any port as output and maybe input

[zenna]

That scope idea becomes too complicated. If an composite arrow takes input from some where in its scope, how do we invert it?

Let's revisit the idea of having all of some ports be implicit

• You can't reuse inports without a dupl
  True, but maybe not a problem

• You can't have shortcut connections directly from in_port to out_port without plugging an identity function in there
  Also, true, but what's wrong with identity

• You can't specify the types of an arrow without its contents
  Also true, more problematic conceptually. But what problem does it cause in practice

A bigger problem is that the interface is not robust We want the nth port to mean something that is stable under permutations of the internals, or even their existence. Do we also want parameter ports to be robust? If a parameter could be eliminated by simplification, it seems like it is not robust.

The real question is what kind of things are parameters, really, in practice?
They encode values in the relation. They encode values in the preimage. But what's the correspondance between x and y and \theta. It depends; there are many possibilities.

So concretely, one way to think about it is to have parameters which are unstable. ii.e simply

• don't connect subarrows to parents