Simplifying `Arranged` type

[ryzhyk]

In the past few days I've been working on code that manipulates sets of Arranged objects with different trace types (TraceAgent, TraceEnter, and TraceFilter). This has proved to be a major source of pain, e.g., I had to refactor my code just to prevent the compiler from failing because of types getting too complex. This is not a show stopper; I am sure I will be able to dance around these issues, but I was just wondering if there is a way to simplify the Arranged type by removing the trace type variable T from its signature, e.g., by converting Arranged.trace into a trace object.

As usual, I am speaking out of my ignorance here as I don't understand the code base well enough to grasp the implications of this change, but I guess there is no harm in asking...

Thanks!

[frankmcsherry]

There is an ergonomic improvement that could land if Rust implements its "implied bounds" RFC (rust-lang/rfcs#2089). The RFC has been accepted (I think) and just needs an implementation, as I understand (perhaps wrongly).

The pain here is that we do need to know the actual trace type not as a trait object (it has associated types, and we need to know what these are). What we could avoid is all of the redundant key, value, time, and diff generic types, which are implied by the trace implementation. However, without implied bounds this results in a comically large set of constraints at each point of use.

[ryzhyk]

The pain here is that we do need to know the actual trace type not as a trait object (it has associated types, and we need to know what these are).

I feared you'd say that. Oh well...

What we could avoid is all of the redundant key, value, time, and diff generic types, which are implied by the trace implementation

That would be nice as well, although frankly writing the trait bounds is less of an issue than this extra Trace type.

[frankmcsherry]

Another thing you could plausibly do is just pick a concrete trace type, which is something that I often do. For example,

pub type TraceKeyHandle<K, T, R> = TraceAgent<K, (), T, R, OrdKeySpine<K, T, R>>;
pub type TraceValHandle<K, V, T, R> = TraceAgent<K, V, T, R, OrdValSpine<K, V, T, R>>;

pub type KeysOnlyHandle<V> = TraceKeyHandle<Vec<V>, Time, Diff>;
pub type KeysValsHandle<V> = TraceValHandle<Vec<V>, Vec<V>, Time, Diff>;

which removes a degree of generality from your code, but it may be a degree you do not care about.

[ryzhyk]

Well, this is exactly the problem, I genuinely need to support multiple trace types. E.g., inside a nested scope I have arrangements created locally (TraceAgent), arrangements entered from the parent scope (TraceEnter), and also filtered arrangements (TraceFilter). None of my code that deals with these arrangements cares about trace type, and yet I have to explicitly handle these different cases.

[comnik]

Chiming in here, because I ran into the same problem and don't know of a good solution either. An additional pain is that any structure that maintains arrangements internally, naturally must have its own versions of enter / enter_at.

My hope was, that at least for the those there might be a way to re-structure TraceAgent, such that it is always assumed to apply a timestamp transformation. This way, enter_at could be implemented entirely via function composition, without affecting the actual trace type. I remember @frankmcsherry thought that would be problematic, for reasons I forgot...