Sometimes when I look at codebases I experience frustration at what I
   perceive as a lack of generalisation.
   An example of this is sympy, I think it's called. It looked to me like
   it contained no mapping between operators and their inverses, for
   writing solvers more efficiently.
   I've bumped into an interesting situation playing with this code. I'm
   not sure how to identify that a part of an expression can be a
   component of a linear combination. I'm considering modeling linear
   combinations as sums of scalar coefficients.
   I'm guessing that this isn't actually complicated, and I just need to
   consider a lot of things that feel inhibited or missing for me.
   1. When considering a linear combination, we ask what is it combining.
   For the uniform distribution sum, we want sums of either scalars or
   uniform distributions, nothing else. So some way to parameterise that
   for other parts.
   2. When flattening expression trees, one often walks them recursively.
   I've drafted a construct I called "interpretation" that holds some idea
   around applying a mixin to an object that is already constructed.
   Basically it just supports "new" and "isinstance" to give some way to
   work with objects using intuition while prototyping.
   So question #2 is how to write code that reinterprets an expression
   tree as a flat linear combination, by recursively interpreting its
   parts that way ... basically the interpretation needs to be
   parameterised on what the linear combination is of, as described in #1.
   Whew, I think ...
   There's always something you haven't thought of. If you "fully" align
   your borg with humanity, they spawn a nanite species on the dark side
   of the moon.