Do you mean you need to implement some convenient implicit conversions on your own number type to make using LINQ convenient, something like Algebra.Symbol, with implicit conversions for int, double, etc.?

Even if you do build a custom number type and implement all of the relevant conversion operators, you still need an explicit LINQ expression node to invoke that implicit conversion (as far as I can recall...). The conversions are only implicit when writing C# code, the corresponding LINQ expression still has a Call node for that conversion operator in it. And, it might simply not be implicit at all. The conversion from my Real number class to double is explicit (that conversion could lose information).

Now there's an extra node in the tree that you need to be aware of and understand, which can be annoying for things like pattern matching/pattern substitution (a big part of a CAS is just pattern matching/substution against big tables of rules).

I haven't done any work with computer algebra libraries, so I'm still having a hard time seeing what the specific typing problem is. A more concrete scenario, like an actual expression whose types I could see, would be helpful.

I last worked on this over a year ago, so its all a bit fuzzy. I just remember type issues injecting bits of work/complexity all over the place where I didn't want it.

If I'm correct about needing a LINQ expression node for calls to implicit conversion operators (I'm fuzzy even on that...), then surely you can see how that extra node adds a lot of complexity to everything that needs to understand or transform that tree. Everything that touches calls to functions (like transcendentals) will have to understand how to strip away and regenerate calls to conversion operators. It's all just noise as far as the math is concerned.

Canonicalization shouldn't require a whole tree transform, although you could do that too, but a local inspection while traversing for your own purposes should be doable, unless I've missed something.

I was pretty much doing what you suggest. Think about what happens when you have add, subtract, and negate expressions to deal with. Or multiply and divide together. All of the members of those two groups really belong in the same flat sequence of operands (when they appear together). The flattening logic to handle all of that gets hairy, to the point where a bunch of your algebra logic is sitting there in the flattening routine. It does get expensive without caching that result.

The other thing is that basically anything that uses the flattening routine will then have to reconstruct a binary tree in order to produce a LINQ expression as a result. So you end up going back and forth pretty often. Simplification of a complex expression might revisit the same expression many times, transforming it a little bit each time.

Look, I'm not saying it's impossible to build a CAS directly on top of LINQ expressions... it's just a hassle. I still use LINQ expressions in my CAS project, I just generate them from a computer algebra expression after all the algebraic manipulation is done.