I was about to send this. Now I see that you've solved your problem. I'll
send it anyway in case it's useful. One note. I would recomment do_one over
chain.
Are you working off of a branch I can see? Perhaps there is a
strategy-idomatic way to get around your issue.
I would normally do something like
def rule1(expr):
...
def rule2(expr):
...
big_function = exhaust(top_down(typed({Trace: do_one(rule1, rule2, ...)})))
On Thu, Nov 1, 2012 at 3:28 PM, 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.
>
>
--
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.
