Vertices of `progCxt` and `e` exclude some sinks

[Roly Perera]

For completeness, the ProgCxt should probably include primitives. This should also be a step towards the above.

Also, closeDefs expects a set of vertices so each closure has a backwards dependency to the some source node. It’s not really a meaningful notion of dependency, but the idea again was to move us closer to sinks as “inputs”. However, we also call closeDefs from eval_module using an empty set of vertices. If we move the vertex associated with a LetRec to the actual RecDefs, then each RecDefs that occurs in a module can supply a vertex for passing to closeDefs. This should remove another source of mismatch between sinks and inputs.

Turns out there were also problems with matrix update and partially applied constructors reusing the incoming vertex, which might not impact this problem but is clearly broken in terms of the injectivity of the map from (sub)terms to addresses.

See also:

• #908
• #906

---

• Move primitives to ProgCxt
• Promote RecDefs from type synonym to data type
• Move annotation from LetRec to RecDefs
• Graph version of matrixUpdate should establish edge to original graph (for consistency with annotation version)
• new could actually take NonEmptySet for now
• Check untraceable vertices are not being allocated inside new
• Find the untracable vertices as clues as to what might be going on
  • 193: Cons cell within constant colours1 in graphics.fld
  • 260: Float constant 0.5
  • 443: Boolean constant False
  • 587: Integer constant 0
• Partially applied constructors shouldn’t reuse incoming vertex
• New Util.Debug.checking attribute for asserting property

[Roly Perera]

Can now assert

let inputs = vertices (γ × eα)
check ((sinks g \\ inputs) == Set.empty) "Every sink is an input"

(or equivalently, although less amenable to spy):

check (sinks g <= inputs) “Every sink is an input”

[Roly Perera]

Mathematically not every sink is required to be an input (there can be outputs that don’t depend on any inputs). However, such a requirement can (arguably) be justified from a provenance point of view, and may be useful in the following sense. If every sink as an input, then the operation of intersecting the vertices of a Boolean selection on the input with the sinks of $G$ preserves negation. I.e. we can negate the Boolean selection and then intersect the selected vertices with the sinks of $G$, and the result is the same as intersecting the original Boolean selection with the vertices of $G$ and then taking the complement with respect to the set of sinks.

This allows us to take the graph GC and “lift” it to an equivalent term-level GC even though the vertices that appear in the terms (environment/expression + value) may be a superset of the sinks/sources of $G$. This is a bit informal but I’m capturing it as this is how our implementation currently works.