Sympy runs on the uni-typed system of Basic, and I previously thought that it was fallen from sky, and I also seen coworkers in my work following that practice naively, But now I concluded that the recursive data structure with only one base type (like Basic) is incomplete and leads to very awkward solutions.
Although it is still possible to represent any mathematical objects in uni-typed system like "Basic" in complete way, but we have no option but to reinvent alphabets, numerals from the scratch and represent numbers like Number(One(), Two(), Three(), ...), which gives technically very inefficient solution eventually. And you would find resemblance of this with things like Von Neumann numerals or Church numerals, which is only theoritically interesting. So it was always something needed to distinguish Basic with Atom, and had loose interface about how things are designed in such way. But I'm trying to rethink about why things had to be designed in the first place, because I believe that this is source of controversies about why sympy objects are too heavy or why sympy objects have very fragile behavior when subclassed, composed. For example, we could allow `args` to be both `Basic` and not `Basic` (we can split all python universe with some interior and exterior), and could have defined Bi-Typed structural induction from objects that fall under `isinstance(..., Basic)` and not. Or there could further be many-typed term system that allows mixing in different types of int, str, or any other python objects with `Basic` in correct positional places, or in some places with regular pattern. I'm trying to have a overview for such type system, because that can serve for building a very general and lightweight framework of computer algebra system. I'm sure that there are some 'champions' trying to cleaning up the core, with following the old practices. But for the worst cases, if any attempts fail for that, we may think of soft archiving the old sympy core and invest on designing the stuff like matrices, physics from the scratch, from the abstract syntax tree level. So the conclusion is everyone should design their own AST if things are extended from SymPy. Actually, I think that the introduction of custom functions, matrices as workarounds for Expr had made things complicated and made sympy fragile of 'shape errors' because they have broken the consistency of sympy in some way, as I see issues revolving around them if any attempt is done for fixing the core. I'm not sure if it has positive progress though. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/3c199913-3d70-4966-a862-daf8a65060e4n%40googlegroups.com.
