need a tick-based version of defer_signal

[jhellerstein]

E.g. I only want to send the most recent result of a fold when I receive a message, not all values of the fold.

        // make data arrive across multiple ticks
        source_iter([()]) -> items;
        source_iter([(), ()]) -> defer_tick() -> items;
        source_iter([(), (), ()]) -> defer_tick() -> defer_tick() -> items;
        
        // drive the ticks quickly
        source_interval(Duration::from_millis(100)) -> null();
        // occasionally trip the signal
        source_interval(Duration::from_secs(1)) -> [signal]gate;

        items = union() -> fold(|| 0, |accum: &mut u32, _item| *accum += 1) -> [input]gate;
        gate = defer_signal() -> for_each(|x| println!("{:?}", x));

With the current defer_signal it buffers up all inputs across ticks, so I will print out all the counts 1, 2, 3. If I had defer_signal::<'tick> I'd only output the most recent count when a signal arrives.

Not sure defer_signal::<'tick> is a good name, but I can't think of a better name that encompasses both.

[MingweiSamuel]

This has some interesting semantics. Really only correct on a cumulative edge

[jhellerstein]

It's unclear what semantics we want.

On reflection, we actually have two independent settings here:

1. Do we empty the buffer on new input?
2. Do we empty the buffer on new signal?

The current implementation is {input: no, signal: no}.

At least three more possibilities:

1. {input: yes, signal: yes}: only produce output if the [input] and [signal] ports both have data in the current tick, producing only the [input] that arrived in this tick. This is equivalent to cross_join::<'tick, 'tick>.
2. {input: yes, signal: no}: in a tick when data arrives on the [input] port, replace the contents of the buffer with the new data from [input] in this tick. On [signal], stream out a copy of whatever data is in the buffer.
3. {input: no, signal: yes}: in a tick when data arrives on the [input] port, append the contents of the buffer with the new data from [input] in this tick. On [signal], stream out whatever data is in the buffer and empty the buffer.

Note that the last 2 are not equivalent to any cross_join, due to the data-driven (not tick-driven) replacement of input data.

I move that we close this issue as WontFix, and open a design issue for defer in the context of the new state and tick logic to come in a future release.

[jhellerstein]

Ps: all of these semantics can be implemented with combos of persist_mut and cross_join, though it's annoying/inefficient to delete everything from a persist_mut.

[MingweiSamuel]

defer_signal clears on {input: no, signal: yes} (drains the buffer on signal). Same as 3.

1. {input: yes, signal: yes} is only equivalent to cross_join::<'tick, 'tick>() if the signal only arrives one time in the tick

[MingweiSamuel]

Concur to close this (for now)

[jhellerstein]

Closing as WontFix, replace with #1219