You might look at multiple dispatch as an improved method of operator overloading, such as what is implemented in Julia. There are also potentially more advanced things which can be useful, such as pattern matching (Mathematica, Haskell).
You have to consider the tradeoffs, however, with expresibility. The most general possible system is a full macro system, which lets you effectively define whatever syntax you want. But the downside to that is that you no longer have a fully consistent language. Someone reading the code for a library must first learn the syntax. To contrast something like Python, which does not have a macro system and has (relatively) limited operator overloading, someone who already knows the language from other uses can read the SymPy code and have a good idea of what things mean (it also helps that SymPy and Python use a fairly strict adherence to standard mathematical notation). To give an example of this, we sometimes wish that Python allowed changing the operator precedence. For instance, we can't use ^ for exponentiation, because even though Python allows overriding that operator, it is fixed at a precedence lower than +, so a + b ^ 2 without parentheses will give (a + b)^2 (^ is XOR). The downside is that new users to Python must learn to use ** instead of ^ for exponents. The upside is that anyone already familiar with Python can see any SymPy expression and know how it will be interpreted, because operator precedence is uniform across all Python code, even if it overloads the operators to mean different things. So I think there's a sweet spot. We have run into limitations of Python's operator overloading mechanism. I personally think that multiple dispatch and algebraic pattern matching are both interesting, but having not used a language that implements either extensively, I can't say for sure if either are that sweet spot. Aaron Meurer On Sun, Jan 14, 2018 at 7:46 PM, Henri Tuhola <[email protected]> wrote: > Hello, > > I would directly want to reach people who have been developing sympy, so I > posted on your mailing list. > > Development of sympy on top of python has not been frictionless, and I think > you know that. Unfortunately only few people know what's even wrong there. > > I am working on a new programming language and found out that the choice of > how to allow extension of arithmetic is a really tough problem to figure out. > Simply implementing arbitrary operator overloading and calling it a day > doesn't seem to be so good choice. > > I wonder that if you had a choice of redesigning arithmetic in Python to > better support sympy, what would you attempt to solve? If you know what you > would do, I would gladly read that. > > Thank you ahead of the time. > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/sympy. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/2ab5c94f-97f2-46d9-aa92-39839a68566a%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6Ld637OHYH8b%2ByWuQBPajm%3DB7SymBxyi0W2-gbhKrQzeQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
