Thank you, it's working well now. It was easy to get rid of the double underscores, because all of my rules are generated by code. (I'm describing data transformations graphically in UML diagrams).
The id slots were actually created to distinguish between otherwise identical facts when loading data into the engine... so I should have realized that this would also be necessary in rule consequences! ====================================== [EMAIL PROTECTED] wrote: (assert) returns FALSE if the fact being asserted already exists. The fact that doesn't get asserted is a "constant" (MAIN::__collection (__data Rubbish)) the first rule asserts it, and then the second one fails to do so, since it already exists. Since __collection has an "id" slot, you could avoid this problem just by giving each __collection you assert a unique id at creation time; for example, you could do something like (deftemplate __collection (slot id (default-dynamic (gensym* col)))) By the way, I have two reactions to your code. One is that the subject matter -- Assemblies, Bills of materials, Products, etc, is something I deal with myself quite often, so it's always nice to see someone else working in the same area. But second, my hair stands on end a little. The slot name "__data" is used internally by Jess to represent the data in an ordered fact, and actually the presence of a "__data" slot may cause some patterns to be processed specially (probably in a way that you would not appreciate.) It's best to treat all names starting with two underscores as reserved for the implementation. If I were you I would definitely change this code not to use such names, either for templates or for slot names. On Feb 9, 2008, at 7:17 PM, [EMAIL PROTECTED] wrote: Hello, When I configure JESS 70p1 with a single rule, and feed it two sets of facts that each (correctly) trigger the rule, the RHS of the rule is behaving inexplicably differently. The RHS plainly calls for the assertion of a fact, which occurs in one case and not the other. Here is the entire rule: (defrule BomType_ltr ?Assembly_1 <- (IPC2511B::Assembly (assemblyRef ?assemblyRef_2) (bom nil) ) ?Product_4 <- (IPC2511B::Product (id ?assemblyRef_2_x) (name ?name_5) (revision ?revision_6) ) (test (eq ?assemblyRef_2_x (AssemblyRefType_to_ShortName ? assemblyRef_2))) => (bind ?F_13 (names__ltr ?name_5 ?assemblyRef_2_x)) (bind ?bom_name_12 (nth$ 1 ?F_13)) (bind ?assembly_name_8 (nth$ 2 ?F_13)) (bind ?step_name_9 (nth$ 3 ?F_13)) (bind ?C_11 (assert (MAIN::__collection (__data Rubbish)))) ; <== Unreliable (bind ?BomHeaderType_7 (assert (IPC2581am1::BomHeaderType (assembly ?assembly_name_8) (revision ?revision_6) (stepRef ?step_name_9) ))) (bind ?BomType_10 (assert (IPC2581am1::BomType (bomHeader ?BomHeaderType_7) (bomItem ?C_11) (name ?bom_name_12) ))) (modify ?Assembly_1 (bom ?BomType_10) ) ) Here is a fragment from the transcript when watchAll is activated: FIRE 1 MAIN::BomType_ltr f-26, f-32, ==> f-118 (MAIN::__collection (__id nil) (__data Rubbish)) ==> f-119 (IPC2581am1::BomHeaderType (__id nil) (affecting nil) (assembly "product29") (revision "revision11") (stepRef "product29")) ==> f-120 (IPC2581am1::BomType (__id nil) (bomHeader <Fact-119>) (bomItem <Fact-118>) (name "product29")) <=> f-26 (IPC2511B::Assembly (__id 272) (bom <Fact-120>) (assemblyRef "product29") (boardOrPanelRef "board7:x") (componentPlacementRefs <Fact-27>) (designRules nil) (drawingRefs nil) (powerSupplyRefs nil) (testConnectRefs nil)) FIRE 2 MAIN::BomType_ltr f-23, f-30, ==> f-121 (IPC2581am1::BomHeaderType (__id nil) (affecting nil) (assembly "product32") (revision "revision9") (stepRef "product32")) ==> f-122 (IPC2581am1::BomType (__id nil) (bomHeader <Fact-121>) (bomItem FALSE) (name "product32")) <=> f-23 (IPC2511B::Assembly (__id 258) (bom <Fact-122>) (assemblyRef "product32") (boardOrPanelRef "board3:z") (componentPlacementRefs <Fact-24>) (designRules nil) (drawingRefs nil) (powerSupplyRefs nil) (testConnectRefs nil)) It will be seen that FIRE 1: * Asserts a new __collection as f-118 (this is expected) * Asserts f-120 with a slot named bomItem containing f-118 (expected) On the other hand FIRE 2: * Does not assert a new __collection fact (unexpected) * Asserts f-122 with a slot named bomItem containing FALSE (assertion expected, FALSE not expected) I hope someone can explain this. Thanks, Art -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED] -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED] --------------------------------------------------------------------
