I would like to point out that the immutability of the core need not change if we follow the propositions in this discussion.
In my opinion the important point here is the implementation of abstract syntax trees for sympy. The minor (from mathematical point of view) details about whether it should be immutable tree or whether side effects and assignments should be allowed in the tree (hopefully not!) are secondary. The use of ASTs seems like the right way to fix http://code.google.com/p/sympy/issues/detail?id=1941 We can have identity crawler that does not change the tree (just returns a copy). The current crawlers (just what Add and Mul do, but much better abstracted). Simplification and canonization crawlers. Special crawler options specific to an object (Units subclass politely asking the crawler to be placed last). Now every time that we need some canonization we subclass Expr. It is not a scalable solution at all. Example: Special treatment of Units in Mul The subclassed Quantum Expr in the quantum module. The need for MatExpr, MatAdd, MatMul... It is a good solution for the current state of the code but it is ugly and it does not scale (what happens when I want both matrices and kets in my expression?) The existence of AST would make the implementation of abstract multilinear algebra or group theory much easier as there won't be any need for subclassing Expr. Just writing a crawler for the tree should be sufficient. It won't be less work, but the incompatibility between the subclasses of Expr will be evaded. On 26 February 2012 16:58, Joachim Durchholz <j...@durchholz.org> wrote: > Am 26.02.2012 20:05, schrieb Sergiu Ivanov: > >> As a functional programming beginner and fan, I can't but agree. I >> was actually quite happy when I heard for the first time that SymPy >> had immutable core, because that allows for much clearer and better >> structured code (at least I see it so). > > > Hm... there's the question what an "immutable core" actually is. Is it the > mathematical objects that the user sees, or is it an internal API for > programmers? > > In the former case, I'd avoid mutability. It's just a conceptual hassle, it > makes semantics-preserving transformations harder (as soon as references are > involved, prohibitively hard for a project of SymPy's scale - you need alias > analysis, and compiler teams spend person-decades on that kind of stuff). > > In the latter case, there's nothing wrong with it. Sure, coding just with > immutable data is fun and far less error-prone, but Python is not built for > that coding style; I suspect such code would be very clean but not very > efficient. > > >> I'd like to ask the question which I believe to be very important: >> what would be the benefit of having a mutable core? > > > That's an interesting question, yes. > And the first one that should be asked whenever important changes are > undertaken, and the first one to look for an answer for. > > Just my 2c. > > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sympy@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
