Dual of `fwd` fails because unused vertices aren’t in graph

[Roly Perera]

For the relationship between De Morgan dual, adjoints and opposite graph to hold, the graph must include all input vertices (e.g. from e and γ). Otherwise, for example, attempting to compute the dual of fwd by complementing the selection and then running bwd on the opposite graph will fail because the complement will include nodes which aren’t in the graph. Currently when we run fromFoldable to construct the final graph, it will only include input vertices that appear as the target of an edge.

Note: graph slicing really needs to produce a reachable subgraph, i.e. only contain vertices that are reachable. After all the whole point of the slice is that we can use to to query a value to see which of its nodes are included in the slice. Would it be reasonable to have two kinds/modes of graph, one where the set of vertices is fixed up front (with the constraint that all vertices mentioned in the edge list are in that set), and one where the set of vertices contains only those mentioned in the edge list?

Alternatively, maybe we should think of the graph resulting from graph evaluation already as a kind of backward slice (for the whole output). Then we would need to ensure that the incoming selection for fwd is a subset of the vertices in the graph. (Since nodes that aren’t used won’t appear in g.)

• fwdSliceDual broken inasmuch as it tolerates non-empty αs0 \\ sinks g0 – replace by (dual gc).bwd
• (Temporarily?) set benchmark tests to run all the time
• Tighten GraphImpl.fromFoldable to prohibit duplicate entries?
  • addIfMissing precludes this – instead start by asserting that existing entry is necessarily empty
  • Push NonEmptySet invariant into extend method
  • Take vertex set (known up-front) as argument, incl. vertices in ambient g ❌ incompatible with graph slicing
  • Rename to fromEdgeList
• With (dual gc).bwd vs. fwdSliceDual, “existing entry necessarily empty” constraint above fails – investigate
  • Verify duplicate keys always provide same information
  • Understand how duplicate information arises ❌ not feasible to debug, doesn’t matter for now given above

See also:

• #780
• #867