This is an idea I've been toying with in my head for a little while (and discussed with @str4d at RWC), but I'm not sure whether whether it would work out in practice, so I'm posting it here for discussion. At a high level, the idea is for ff_derive to use a similar strategy as is used by Eigen, particularly its basic internals and lazy evaluation mechanism to provide optimized implementations of entire subexpressions. For instance, in a C expression like

mat1 = -mat2   mat3   5 * mat4;

Eigen will skip producing temporaries and instead produce a single fused evaluation loop. Eigen does this using C template metaprogramming, while ff_derive would use type-level programming with various trait bounds. This is (thankfully) a less powerful model than C templates but I think that it's still possible to do something similar to what Eigen does.

How would this work for ff_derive? Here's one idea. Rather than generating a single type for the finite field (let's call it Fp: Field), ff_derive would generate a main user-facing type (let's call it Fp as before), but the generated type Fp would have impls of Add, Mul, etc whose Outputs would be inner types implementing Into<Fp>. These inner types would also have ops impls of their own, so that a user could write expressions like

let a = (x   y) * z;

and have this produce an optimized implementation of the entire expression. (One thing we cannot do in Rust compared to C is overload the assignment operator, so we would likely need users to add .into() to each expression they want to evaluate to an Fp, but I think this isn't a big deal).

There are varying levels of sophistication for this on the ff_derive side, but the obstacle on the ff side is that with this approach it's not possible to implement Field, because the Field trait requires that the Output of the required ops traits is Self. Weakening this to Into<Self> would (I think) remove this obstacle.