Truth maintenance

[eliaslevy]

As far as I can tell, Grule doesn't support truth maintenance. I.e. the automatic retracting of inferred facts when the facts used in the inference no longer hold.

If that is correct, it is worth to mention it in the documentation.

[niallnsec]

When a fact is changed in GRL any evaluated statements which have been cached are discarded. The only edge case is if a user provided function call changes a fact in any way, it must inform the engine using the Changed() builtin function as described in the documentation.

[eliaslevy]

I suppose my comment may be moot, as Grule doesn't allow you to insert a new fact from a rule or to retract a fact from a rule.

In Drools you could have a rule like:

rule "When there is a fire, sound the alarm"
when
  exists Fire()
then
  logicalInsert(new Alarm())
end

This inserts an Alarm fact if there is a Fire. If the Fire fact is then retracted (we are safe!), the Alarm fact is automatically retracted by the truth maintenance system. This is not something Grule can do.

In Grule we'd have a rule like:

rule SoundAlarm "Sounds the alarm if there is a fire" {
  when
    AlarmSystem.fireDetected == true
  then
    AlarmSystem.turnAlarmOn = true;
}

If AlarmSystem.fireDetected becomes false, AlarmSystem.turnAlarmOn is not returned to its previous value. Rather, we must implement a rule to turn off the alarm.

[newm4n]

Umm come back to that, This project indeed inspired by drools, but Im not aiming to immitate all drools years of refined complete features. Its a much simpler implementation. Youre more than wellcome to enhace the software, to contribute for the benefit of our opensource community, or fork it to suit your own business case. Your feed back is valuable and gives us ideas on next improvement. Maybe, just maybe one day this project can be as good as drools but still be simple.

[eliaslevy]

@newm4n apologies if I came across as not appreciating Grule. It's a great project! I merely wanted to say that it would be good to specify those things that Grule doesn't support to make it easier for those evaluating the project to determine whether it suits their needs. I happen to find myself on that position at the moment and evaluating a number of production rule systems, so I thought I'd mention it.

[newm4n]

@eliaslevy, I sincerely appreciated your effort to take Grule into account as one production rule system you evaluate.

I just want to make a point that its a fact that Grule implementation is indeed inspired by Drools and also a fact that Grule is not Drools in every ways. You might find out that their approaches are different and they may work differently for many, if not all, cases. I don't feel that we have the obligation and responsibility to documents every single differences between them. Another thing is Grule will not try to imitate Drools; its not the goal I have in mind, only simplicity.

I'm dreaming a book with title like "Migrating from Drools to Grule" that should guide some one to achieve that, or a more direct "Drools vs Grule" book (LOL, im talking as if Grule is as popular as Drools), but until such book exist we will only document things to to help people know about how to use Grule and try to help them through discussions like this.

Your feed back is very much appreciated. But you couldn't expect us to note down all the differences in the Docs. If you expect that Grule should and must support all that what Drools can do, you will be disappointed and you should look somewhere else. Maybe other Go, Ruby, Javascript implementations or even those very expensive variants out there.

Best of luck to you in your search for most suitable production rule system and again, thanks a lot for evaluating Grule. 😉