deep operator elaborations not recognized as operator elaborations

[GoogleCodeExporter]

Description From Bob Marinier 2004-06-17 12:31:17 (-) [reply]
Consider these rules:

sp {propose
   (state <s> ^superstate nil)
-->
   (<s> ^operator <o> +)
}

sp {elaborate*operator
   (state <s> ^operator <o>)
-->
   (<o> ^foo <f>)
   (<f> ^bar <b>)
   (<b> ^test test)
}

Under o-support-mode 4, the second rule is supposed to get i-support since 
all 
the rule does is elaborate the operator.  However, Soar generates a 
warning:

WARNING:  operator elaborations mixed with operator applications get 
i_support 
in prod elaborate*operator

The problem is that the elaboration structure is not all directly connected 
to 
the operator, so the code which checks for this thinks the (<b> ^test test) 
is 
not an operator elaboration.

The problem appears to be in this if statement in p_node_left_addition in 
rete.c:

...
else if (current_agent(o_support_calculation_type) == 4 &&
         (rhs_value_is_reteloc(act->id)) &&
         (temp_tok->w->value == get_symbol_from_rete_loc(
                                 (byte)rhs_value_to_reteloc_levels_up(act-
>id),
                                 (byte)rhs_value_to_reteloc_field_num(act-
>id), 
                                 tok,
                                 w)))
        {
           op_elab = TRUE;
        }
...

Unfortunately, what this does is beyond me, so I don't know how to fix it.  
Stepping through the code, it is the final test in this if statement which 
is 
failing.  Specifically, the macros generate 0's for the first two 
arguments, 
and the returned pointer doesn't match temp_tok->w->value.  However, if I 
change the second argument to a 2, then it returns the correct pointer.  I 
don't know if this is a fluke or a hint at how to fix the problem.  Looking 
at 
the code for the macros and for get_symbol_from_rete_loc does not make 
anything 
clearer.
------- Comment #1 From Bob Marinier 2007-02-15 21:10:15 (-) [reply] ------
-
This turns out to be tricky, because a deep operator elaboration could also 
be
linked to the state, in which case it isn't clear which takes precedence.  
This
affects even simple code like water-jug, since the jugs are on the state 
but
are copied to the operator to make them easy to access.  In that case, the
changes have to be o-supported for water-jug to work.

One suggestion is to default to o-support when it's not clear.  Another
suggestion is to use i-support when wmes are created through the operator, 
and
o-support when they are created through the state (that is, when the path 
in
the rule goes through one or the other).  This would require water-jug to 
be
recoded, but is more flexible.  However, there could still be the case when
both creation paths exist in the same rule.

Original issue reported on code.google.com by voigtjr@gmail.com on 23 Jul 2009 at 4:02

[GoogleCodeExporter]

Original comment by voigtjr@gmail.com on 23 Jul 2009 at 5:29

• Added labels: Imported-Bugzilla

[GoogleCodeExporter]

Original comment by voigtjr@gmail.com on 23 Feb 2010 at 7:41

• Removed labels: Milestone-9.0.2