Proposal to attempt maintaining Rule insertion order

[newm4n]

From RuleEngine_en.md,

Because Go's map types are not guaranteed to preserve input order, it is not safe to assume that rule evaluation order will match the order in which Rules are added to a Grule knowledge instance.

I just thinking, when user insert the rule with no salience specified. We could apply the salience not to the default of 0, but we can insert them with the smallest known salience -1.

The thing is, if a user wants a specific rule (for example rule "AClosingRule", to be called for the last time, he can only insert that rule as the last rule to insert. Other wise, the next inserted rule with no salience will be even lower to that "AClosingRule" rule.

This approach may be also valid for engine with rule set generated from database. where select statement return an ordered rule set to be feed to Builder every-time the KnowledgeLibrary is created a new.

I fear this may cause un-necessary confusion or complexity. Or just leave it at it is let the user manually set their own salience so it be more clear to them.

[jinagamvasubabu]

HI @newm4n, can we use orderedmaps instead of following the proposed approach

I found a good one online - https://github.com/elliotchance/orderedmap.

[newm4n]

@jinagamvasubabu that could work. But

First, it will definitely have performance impact. The benchmark shows performance drop comparing to vanilla map https://github.com/elliotchance/orderedmap#performance

Second, Its not quite straight forward... I mean, its not working with range keyword.

I look into the orderedmap source code. It's backend by a map (for fast index access) and container.list (for manipulation insert,delete) but IMHO suffer direct access (since it need iterator).

Come to that, we could imitate the approach of the ordered map. Where the KnowledgeBase would maintain a map and a slice. Both are referencing to a *RuleEntry

[newm4n]

Hmm... that would not work. Insertion order would break in the conflict set resolution. There's no point of maintaining a slice.

[niallnsec]

What if we changed to use a doubly linked list for the main rules structure with a map acting as an index? That way we get both fast index lookup via the map when needed and a traversable list in an order which we can control. Additionally, because pointer replacements are atomic linked lists can be implemented with no branching logic or locking even in multi threaded scenarios, so there should not be a performance hit, there may even be a slight improvement over the native map.