> I don't think it's a good idea. > > * This logically implies 1(x) == 1, which is surprising, to say the > least. I have no comment here as I do not see exactly what the problem is.
> > * Consequently, this gives most objects a dual role as themselves and > as a constant function returning themselves, in clear contradiction > with the single responsibility principle. Why dual? Why not just "a constant function returning itself". Again, I suppose that I just do not understand the argument. > > * It makes it impossible to distinguish between callables and > non-callables. The __call__ method of Expr does exactly this type of distinction when making the recursive calls. Admittedly it can be done in a cleaner way, but it works. Moreover, the fact that nothing has failed in the tests shows that such distinction has never been used. sympy is basically only working with expressions and almost never with functions (the semantics of diff for example). > > * Why is this new behaviour limited to Expr? Callability and > existence of arithmetic operations are orthogonal concepts. I did not understand the question. A possible answer if I understand would be: The idea is to have an identity between "1 + function(arg -> f(arg))" and "function(arg -> 1+f(arg))". It is a very frequent "abuse of notation". Admittedly, "abuses of notation" should rarely be implemented in CAS, however this does not interfere with the rest of sympy and it can be made rigorous by stating "arithmetics and function definition commute". As I already mentioned a precedent can be seen in "Functional Differential Geometry" by Sussman and Wisdom. > > * What about function arity? If f = Lambda(x, x) and > g = Lambda((x, y), x+y), what is 1 + f + g? Quite seriously I would answer "Why should we care?". It would be nice to have partial (lazy) evaluation, but even if we do not have it, this would be considered just an mis-formed expression that should not be created (I like more the partial evaluation possibility). Also, we have already discussed something like this during the argument about "symbolic lazy nsolve" https://github.com/sympy/sympy/pull/968 . I would very much like to continue the discussion about this pull request as I had some unanswered questions. The most important one was about the "infinitely evaluated" semantics used by Mathematica. I left a reference to some documentation on the subject but I did not get any answers. > > * 1 + Function('f') can't work anyway, because Function('f') is a > class, not a sympy object. This is a second time that you mention this argument. I have some questions about it. Actually Lambda has the same semantics as Function and it works perfectly with this (just because it subclasses Expr). I have some open questions about this on our recent discussion on the mailing list "why is Lambda not subclassing Applications". More generally, as I have mentioned in another discussion, I do not see why Basic and Expr are separate. But this is tangential enough to derail the discussion, so I will just open a new thread about it later. The usual disclaimer: I may very well be wrong and this may be a bad idea, but I do not understand or do not find obvious the current arguments against. -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
