Actually, now I see that I do not use the correct semantics. I should use chain for my small rules and only then do the conditions, typed, etc.
I consider my previous arguments void. Thanks for the explanation. On 1 November 2012 21:28, Stefan Krastanov <[email protected]> wrote: > I still think that it would be nice to have them as decorators. > > For instance I have many typed rules. At the moment I write this numerous > times: > > def my_rule(expr): > ... > my_rule = exhaust(top_down(typed({Trace: my_rule}))) # to be optimized > > And I am sure that I will not need it in any other way. > > Having them as decorators, indeed will not permit getting the > undecorated version at runtime, however during refactoring it will be > trivial to get it. And I suppose this is when it will be needed. > > offtopic: I think that the API for `typed` deviates from the "stuff, > rule -> rule" signature. > > On 1 November 2012 20:21, Matthew Rocklin <[email protected]> wrote: >> I've thought about this a bit. Yes, strategies could very naturally be >> extended to decorators and it would make application more beautiful. My >> concern with this is that when you decorate a function you lose access to >> the undecorated form. While it might make the code to solve your >> problem-of-the-moment syntactically nicer it fouls up reusability with >> different strategies. >> >> The functions are supposed to be just mathematical logic >> The strategies are supposed to be just algorithmic / control logic >> >> We should be able to mix them freely and we should allow others to mix them >> later. Decoration mixes them but hides the components. Decoration >> "complects." >> >> It makes sense to have the decorators around because you can always choose >> to not use them. I'm afraid that this will encourage bad behavior. >> Strategies are sort of a trick to convince everyone to write accessible >> sub-functions that can be composed later by others. >> >> >> On Thu, Nov 1, 2012 at 2:07 PM, Stefan Krastanov >> <[email protected]> wrote: >>> >>> I am sorry if this is explained somewhere or already discussed. >>> >>> Many of the strategies (all of them?) sound like very natural >>> decorators on rules. Any plans to support this syntax. It does not >>> need to clash with the current one (except for reordering or args). >>> >>> After all >>> >>> @f1(arg) >>> @f2 >>> def func(): pass >>> >>> is equivalent to >>> >>> def func(): pass >>> func = f1(arg)(f2(func)) >>> >>> -- >>> 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. >>> >> >> -- >> 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. -- 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.
