Question: Would it make sense to allow a custom function to Forget a struct value or Retract/Complete the current rule?

[tpihl]

Is your feature request related to a problem? Please describe.
I am trying to make the rules focus purly on "what", not "how" by hiding the "how" inside custom functions on the facts. This means that i may update one/many variable(s) in "my" fact as well as in other facts. The function may also need to make sure that the rule that called it is retracted based on some computation hidden in the function.

Currently my rules are full of Forget and Retract statements that adds no value to how to understand/define the rule itself.

Describe the solution you'd like
Ability to from within a fact's custom function inform about changed variables/facts (just as Forget in a rule) as well as to retract whatever rule that called me from the next round of evaluations. Maybe even declare Complete (less need but maybe for consistency?

Describe alternatives you've considered
A way to change the default so that all variables are forgotten every round and by default retract all rules if they fired this round. This would require a way to "unretract" a rule if it should be able to fire also next round and will unfortunatly loose ALOT of performance :(

Additional context
I am a Rookie (capital R) to rule-engines and if this question in any way crosses any boundary, please let me know.
Or if there is easier/better ways to do what i want. My goal is to use the rule engine as common language between business and technical implementation, enabling normal users to both understand the rules and make them able to suggest new rules to better describe their business with practices/processes and exceptions.

[newm4n]

@tpihl

Those functions, Retract, Complete, etc, is actually a built-in function defined in ast.BuiltInFunctions .
If you can obtain (or recreate) the BuiltInFunctions instances, you can call those functions from your fact functions.

If you take a look at this snippet , you can see how BuiltInFunction is added into Datacontext under the name DEFUNC. You can imitate this to gain access to builtin functionalities.

type MyFact struct {
	builtIn *ast.BuiltInFunctions
	IntAttribute     int64
}

func (mf *MyFact) DoItAndRetractSomeRule(sentence string) string {
	// do it 
	// ,,,
	mf.builtIn.Retract("SomeRule")
	return fmt.Sprintf("SomeRule retracted")
}

func (mf *MyFact) DoThisAndComplete()  {
	// do this stuff
	// ...
	mf.builtIn.Complete()
}

func (mf *MyFact) DoThatsAndRedeploy()  {
	// do that stuff
	// ...
	mf.builtIn.Knowledge.Reset()
}


func TestTutorial(t *testing.T) {
	// Prepare knowledgebase library and load it with our rule.
	knowledgeLibrary := ast.NewKnowledgeLibrary()
	ruleBuilder := builder.NewRuleBuilder(knowledgeLibrary)

	drls := `
rule SomeRule salience 10 {
    when 
        true
    then
        MF.DoItAndRetractSomeRule();
}

rule FinalRule salience 0 {
    when 
        true
    then
        MF.DoThisAndComplete();
}
`
	byteArr := pkg.NewBytesResource([]byte(drls))
	err := ruleBuilder.BuildRuleFromResource("Tutorial", "0.0.1", byteArr)
	assert.NoError(t, err)

	knowledgeBase := knowledgeLibrary.NewKnowledgeBaseInstance("Tutorial", "0.0.1")

	dataCtx := ast.NewDataContext()
	myBuiltInFunction := &ast.BuiltInFunctions{
		Knowledge:     knowledgeBase,
		WorkingMemory: knowledgeBase.WorkingMemory,
		DataContext:   dataCtx,
	}
	myFact := &MyFact{
		builtIn: myBuiltInFunction ,
	}
	err = dataCtx.Add("MF", myFact)
	assert.NoError(t, err)
	
	
	engine := engine.NewGruleEngine()
	err = engine.Execute(dataCtx, knowledgeBase)
}

In my opinion, calling built-in functions from your custom function will reduce rule behaviour visibility. It could make harder for you to debug missbehaving rule execution since retraction, completion command is done by your function. So my advise is, do this as long as you know what you're doing.

I hope this help.

[tpihl]

Looks very promising. Is there any way here to know what rule actually is active (calling "me")?

[newm4n]

Did you mean this ? https://github.com/hyperjumptech/grule-rule-engine/blob/master/docs/MatchingRules_en.md

[tpihl]

Not really. My helper function can be called from many rules, and from it I cannot know what rule to retract. Forget will work, complete also but not retract

[newm4n]

At the earlier version of Grule, there was a Producer/Consumer pattern implemented. But I decided to remove them as, at that time, the producer code clutter the engine code. This makes me think if I should reintroduce a simpler mechanism to invoke a callback function within datacontext. For example, to notify that a rule being executed.

[tpihl]

Hi again!

Did you proceed any further on how we could make our struct methods smarter to simplify the rule definitions (and avoid repeated mandatory stuff that is so easy to forget, like retract or clean statements?