Handling of unused return values from collapsed dataflow functions.

[JustusAdam]

It has transpired that situation can occur where one of the return values from a collapsed dataflow function is not used.

Example

smap id [...]

This creates a graph similar to this

let (i, ctrl, size) = dataflow ohua.lang/smapFun<0> (input_0) in
let (r) = ohua.lang/id<1> (i) in
let (result) = dataflow ohua.lang/collect<8> (size, r) in
result

Note that ctrl is never used.

Similarly we might construct a situation where smap is used only for side effects like

smap (\_ -> do_side_effect () ) [..]

let (i, ctrl, size) = dataflow ohua.lang/smapFun<0> (input_0) in
let (unit_lit_0) = dataflow ohua.lang/ctrl<2>(ctrl, ()) in
let (r) = ns/do_side_effect<1> (unit_lit_0) in
let (result) = dataflow ohua.lang/collect<8> (size, r) in
result

Here the i binding is unused.

The problem is that functions like smapFun take care of their own destructuring and expect the corresponding return arcs in the rust backend. The real problem is that our graph representation that the compiler returns does not account for these missing arcs (they simply do not show up).

The question is what to do about it. It is, I think, unwise to work around this in the backend by looking whether there are missing indices. Because this only works so long as it is not the last argument (how would we know its index is missing) or we also track how many arguments are expected.

I think its simpler to add a list of "dead arcs" to the graph representation. And the backend can do with it as it pleases.

[sertel]

This is already implemented as DeadEndArcs on the Rust backend. It finds arcs that do not have a target and inserts these.

[JustusAdam]

Not quite, tough the two are definitely related. Because the ctrl operator is now removed by the compiler the graph representation does not include the arc anymore. I already talked to felix and he agrees that recording these special dead arcs in the the json is a good way to provide the backend with the necessary information to handle them.

[sertel]

Oh, I should have stated that more clearly, sorry. I totally agree to communicate this information explicitly to the backend. I just wanted to point to the fact that the notion of a DeadEndArc is already present in the current backend implementation. So I think we are on the same page.