Public tactics

differential-dataflow/src/operators/join.rs

@@ -26,7 +26,7 @@ use crate::operators::ValueHistory;
 /// The trait is parameterized by the output container `C`, not by the builder that assembles it: a tactic
 /// yields finished containers, and how it produces them (pushing records into a [`ContainerBuilder`], or
 /// otherwise) is its own concern.
-pub(crate) trait JoinTactic<B0: BatchReader, B1: BatchReader<Time = B0::Time>, C> {
+pub trait JoinTactic<B0: BatchReader, B1: BatchReader<Time = B0::Time>, C> {
     /// Prepare the join of two lists of batches into an iterator of output containers.
     ///
     /// The supplied `fresh` and `meet` indicate respectively which input is "novel", and should drive the
@@ -39,7 +39,7 @@ pub(crate) trait JoinTactic<B0: BatchReader, B1: BatchReader<Time = B0::Time>, C
 /// The fresh batch's times all lie at or beyond the capability, so its side is not advanced by the
 /// capability's meet; the opposing accumulated trace is. The marker also selects which queue a unit
 /// joins, so a burst on one input cannot starve the other.
-pub(crate) enum Fresh {
+pub enum Fresh {
     /// The first input (`B0`) contributed the fresh batch.
     Input0,
     /// The second input (`B1`) contributed the fresh batch.
@@ -77,7 +77,7 @@ where
 /// compaction) and routes the per-batch work through the tactic. It requires only `TraceReader` of its
 /// inputs, never `Navigable`: it extracts trace batches via `batches_through`, and building cursors over
 /// them (if that is how the join proceeds) is the tactic's concern.
-pub(crate) fn join_with_tactic<'scope, Tr1, Tr2, T, C>(arranged1: Arranged<'scope, Tr1>, arranged2: Arranged<'scope, Tr2>, mut tactic: T) -> Stream<'scope, Tr1::Time, C>
+pub fn join_with_tactic<'scope, Tr1, Tr2, T, C>(arranged1: Arranged<'scope, Tr1>, arranged2: Arranged<'scope, Tr2>, mut tactic: T) -> Stream<'scope, Tr1::Time, C>
 where
     Tr1: TraceReader+'static,
     Tr2: TraceReader<Time = Tr1::Time>+'static,

differential-dataflow/src/operators/reduce.rs

@@ -29,7 +29,7 @@
 /// Unlike join, reduce does not suspend: its output is at most linear in its input, so a single
 /// `retire` runs the whole `[lower, upper)` interval to completion rather than yielding under a fuel
 /// budget.
-pub(crate) trait ReduceTactic<B1: BatchReader, B2: BatchReader<Time = B1::Time>> {
+pub trait ReduceTactic<B1: BatchReader, B2: BatchReader<Time = B1::Time>> {
     /// Retire the interval `[lower, upper)`, producing the output batches it informs.
     ///
     /// It is presented with the pre-existing input batches and output batches (those before `lower`),
@@ -105,7 +105,7 @@
 /// `TraceReader` of its input and `Trace` of its output, never `Navigable`: it extracts batches via
 /// `batches_through`, and building cursors over them (if that is how the reduce proceeds) is the
 /// tactic's concern.
-pub(crate) fn reduce_with_tactic<'scope, Tr1, Tr2, T>(trace: Arranged<'scope, Tr1>, name: &str, mut tactic: T) -> Arranged<'scope, TraceAgent<Tr2>>
+pub fn reduce_with_tactic<'scope, Tr1, Tr2, T>(trace: Arranged<'scope, Tr1>, name: &str, mut tactic: T) -> Arranged<'scope, TraceAgent<Tr2>>
 where
     Tr1: TraceReader + 'static,
     Tr2: Trace<Time = Tr1::Time> + 'static,
@@ -545,13 +545,13 @@
                 }
             }
             #[inline(never)]
             pub fn compute<'a, K, C1, C2, C3, L>(
                 &mut self,
                 key: K,
                 (source_cursor, source_storage): (&mut C1, &'a C1::Storage),
                 (output_cursor, output_storage): (&mut C2, &'a C2::Storage),
                 (batch_cursor, batch_storage): (&mut C3, &'a C3::Storage),
                 times: &Vec<T>,
                 logic: &mut L,
                 upper_limit: &Antichain<T>,
                 outputs: &mut [(T, Vec<(V, T, D2)>)],