Dynamic salience

I'm torn between debugging and fixing pyRete's current RuleCompiler and refactoring it altogether. In order to keep up apperances I've been focusing on other things these past few weeks. So when Mark announced support for Dynamic Salience in JBoss Rules I naturally decided to add it to pyRete ;-)

Dynamic Salience was actually already on my to-do list for pyRete but I wouldn't have spent time looking into it if Mark hadn't posted about it. It turns out that it's not too difficult to add it. This time, I'm doing a few things differently from Clips though.

First of all, Salience evaluation is local (per Rule) and not global as in Clips.

Also, technically, there won't be any difference between Static and Dynamic Salience, both will always have an expression evaluated when needed. The only real difference is that using a Python constant (an integer) won't ever change the Salience and will therefore appear to be static.

And last, but not least, I'm not sure about how to differentiate between Clips' concepts when-activated and every-cycle. I'm going to have to add some meta-data to the Rule Syntax one way or the other. At the moment, Salience is always calculated when a Token is added to a Rule's Production Node. I'm hoping that's enough but we'll have to see about that. Also, I'm worried about doing too much work in the match-resolve-act cycle if I allow every-cycle. pyRete is slow enough as it is.

[2007-05-31] Update: I've been trying to figure out more about Clips' behaviour in relation to dynamic salience (see my comments on Mark's post).

What Mark has implemented for JBoss Rules and what I have done for pyRete is different in many ways from what's been implemented in Clips and my questions about the differences between when-activated and every-cycle have been answered. The design decisions of allowing the salience declaration to access LHS variables and to only calculate salience when a Token reaches a Production Node makes it unneccessary to implement both.