Supporting OR

I'm in the middle of rewriting pyRete's Rete implementation. The one it's using now is complicated and rather badly designed. I've kept adding types of nodes and functionality to it and it's starting to fall apart.

In connection to this I've also started to plan support for some things I've ignored up until now. One of them is support for LHS expressions using OR.

At first, I really thought it would be "easy" since a rule using an OR expression can logically be divided into two or more rules with duplicated terminal nodes. Silly me. But as usual Peter[1] and Charles have thought a lot more about this than I have and luckily they're willing to share.

I'm still planning support for OR in the next release of pyRete but exactly how it will work I don't know.

[1] Peter's blog (The Road Hits the Rubber) is unfortunately still private.

3 kommentarer:

woolfel sa...

Implementing OR isn't that hard really. More accurately, simple OR isn't that hard. Complex nested OR gets very tricky and only few people like Ernest, Gary Riley and Charles Forgy know it really well. There's actually an old comment by Gary about optimizing subnetworks for nested OR statements. It's one reason I've hesitated implementing OR in Jamocha. For the simple case it's rather trivial, but once an engine supports OR disjunction users will ask for nested OR.

OR is useful, even if users tend to abuse it and then scream "it doesn't work like i expected." It's when an user gets to that point that they realize writing rules is quite tricky :)

Johan Lindberg sa...

Before reading yours and Charles' comments I hadn't even thought of the more complex nested cases of OR.

Implementing the simple (non-nested and short-circuiting) OR is a breeze in pyRete. The only reason I've waited so long is because I really want a better structure for the Rete implementation classes.

I think that the hardest thing will actually be to expose (as rule syntax/semantics) these two distinct variations of OR to the rule developer.

It's tricky since I'm trying to stay as close to Python as possible. There's no way to express this type of OR in Python, but then again there's no way to express the type of NOT pyRete uses either.

Another way to do it is of course to not allow nested OR ;-)

woolfel sa...

yeah, I've been leaning towards not allowing nested OR disjunction for a while now. It just lead to abuse and convoluted rules. Most people have a hard time keeping track of things, let alone a complicated rule.

Even if a person understands what it means when they wrote it, no one else will be able to understand it without lots of head scratching. And will that person remember why they wrote the rule that way 5 months later. In the end, a rule is a kind of code and having convoluted rules is no different convoluted code. of course some developers will moan that nested OR is not allowed.