On Thu, Nov 7, 2013 at 1:22 AM, Joachim Durchholz <j...@durchholz.org> wrote: > Am 07.11.2013 05:42, schrieb Aaron Meurer: > >> Yes, we still need multiple dispatch, > > > I'm wondering - what do we need that for? What problem does it solve?
See the above discussion. > > >> but it's a really hard problem, > > Actually, a wrapper-based solution shouldn't be too hard to do, so the > implementation side of things is just the amount of work. The implementation isn't what's hard. Python is dynamic enough that anything you come up with can be implemented well enough. The issue is how to actually do it, logically. How should the API look? How should the logic of it work, especially regarding conflicts and subclasses. How do we avoid having to define all n*n*k possibilities (for n classes and k arguments). > > At the conceptual level, it's indeed hard, it involves trade-offs with > nonobvious consequences. > I once tried to work it out for Eiffel, or for statically-typed languages, > and found (to my dismay) that it involves trading off language properties > that I all considered essential. (I do not think that having a > dynamically-typed language like Python helps here; in my experience, dynamic > typing just shifts the problem from the language designer's shoulders to the > library designer's shoulders, with the library designers having less > experience to deal successfully with the issues.) > > However, with a concrete goal in mind and when applying it to a restricted > problem domain, maybe a trade-off can be found that might work. > That's why I'm asking about the problem. Knowing the problem would help me > finding the path of least pain. Well, F.B. may have his own view, but as far as I'm concerned, I only care about one thing: I want custom classes to be able to define their own behavior without having to modify the core. This is important for two reasons: first, we want our users to be able to do things without having to monkey-patch or subclass* or literally modify the core classes, and second, we want to be able to do this within SymPy itself, so that the core isn't such a huge mess, referencing other parts of SymPy that it really shouldn't need to know directly about. (*) - I'm actually not sure if subclassing the core classes is completely wrong. It seems it actually can be useful in some cases. > > >> no one has been working on it > > Yeah, and I'm not volunteering either since my time is too limited. > What I can do is describe the issues and enable informed design decisions. > > >> I'm not even sure what the best solution is yet > > What trade-offs are on your radar there? At this point, I don't even know how to do it *at all*, so I'm not even that far. Some things are not clear to me. For example, if you want to say x defines x + y as one thing and y defines x + y as another thing, who wins? Does it matter if y is a subclass of x? Another question, if we have x + y + z and x, y, and z all define addition behavior, how do we avoid performing O(n**2) computations just to construct the Add object? Even for fixed argument dispatch, this is still a concern. Aaron Meurer > > > -- > 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 post to this group, send email to sympy@googlegroups.com. > Visit this group at http://groups.google.com/group/sympy. > For more options, visit https://groups.google.com/groups/opt_out. -- 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 post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
