Anyone are to comment?

(1) RHS variables
CLIPS only allows you to access values that have been bound to in the LHS part of the rule. I want the developer to access ANY value in any fact that satsified the LHS of an expression.

I guess we can blame that on my RDBMS background but in SQL terms I can access any field related to any of the tables I've specified in the FROM or JOIN clause. I think the same thing should be available to reteSharp developers. It seems silly to build 'empty' BetaNodes just to achieve some variable binding for the RHS part of the rule. It's also inefficient (I think).

 I think this means we will build the "dtokens" in a slightly different fashion than the standard Rete algorithm. I dont think this is a big deal.

(2) Conflict set values
It is not at all clear to me how the data in the Conflict Set is supposed to be structured. Clearly all of the data associated with a variable value must be grouped together. I guess these are the "dtokens" but its more than that.

Let me try this by observation :

Given this "workspace" :

(deftemplate Car (slot Color) (slot Make))
(deftemplate Truck (slot Color) (slot Make) (slot Weight))
(deftemplate Jeep (slot Color) (slot Make))

(deffacts Init
 (Car (Color White) (Make ReteI))
 (Truck (Color White) (Make SwampGasI) (Weight 2000))
 (Jeep (Color Red) (Make MykroMark))
 (Car (Color Blue) (Make ReteI))
 (Truck (Color Blue) (Make SwampGasI) (Weight 2100))
 )

(defrule rule1
 (Jeep (Color ?color2) (Make ?JeepMake))
 (Car (Color ?color) (Make ?CarMake))
 (Truck (Color ?color) (Make ?TruckMake))
=>
(printout t "Car color is color '" ?color "' Make '" ?CarMake "'" crlf)
(printout t "Jeep color is '" ?color2 "'" crlf)
)

Here are the results :

Car color is color 'Blue' Make 'ReteI'
Jeep color is 'Red'
Car color is color 'White' Make 'ReteI'
Jeep color is 'Red'

So it seems like the result set is a CARTESIAN PRODUCT of all of the bound variables.

1. Update the AlphaNodes for each patternCE (matched or non-matched).
2. If all AlphaNodes have been satisfied, set a boolean indicating the patternCE is AlphaSatisfied.
3. For each BetaNode in each patternCE, add a reference to the BetaNode (assuming the fact has a data for the slot).
4. Start at the terminal node and walk up the LeftInput tree and add the fact reference for all matching BetaNode references.
5. If the current fact appears in all BetaNodes for all patternCEs, the the rule is BetaSatisfied.
6. If the rule is AlphaSatisfied and BetaSatisfied, the rule is activated.

Clarifications :

• When a fact is ASSERTed into the network, this refers to the network inside one reteEngine instance. There is some thought to opening this up and perhaps defining a *global* engine where all facts (across all reteEngines) are visible. This will be worked on in a later version.
• ASSERTing a fact (or any fact modification for that matter) will be performed in a separate operation from the "evaluation" of the fact for the rules it affects. This approach may make the code a bit cleaner and simpler ... this is a good thing :-)
• MODIFYing a fact will not be a fact RETRACT/INSERT. MODIFYing a fact will be an update in place for the AlphaNodes and BetaNodes and a reevaluation of the affected rules.

Once this code is written, we need TEST CASES .... LOTS of them. Any suggestions, code, data, ideas etc. are appreciated.