Attached is a simple Soar program that drops into a substate and then returns a
result structure (^foo.bar ran) to the superstate.
There are two substate apply rules (with the same name). The first one is a
standard apply rule that directly creates the result structure. This works as
expected -- the substate goes away and the result structure remains. (To see
this, reorder the applies so this one comes second, or comment out the other
one -- they have the same name.)
The second one tries to be clever and uses a description of the result
structure on the operator to create the result. It does this by firing twice in
parallel. In this case, when the substate goes away, the ^foo part stays, but
the ^bar ran part retracts. Looking at the justifications, only the ^foo part
is included in the justification.
I suspect that, because the rule fires twice in parallel, that the
instantiation that creates ^bar ran is local to the substate, and thus only
o-supported wrt the substate. The ^foo part is a proper result that just
happens to have ^bar ran as substructure (but that substructure was not
actually returned as a result). So Soar does not recognize ^bar ran as a
result, and it retracts with the substate.
Laird comments:
I took a quick look. This looks to be a race condition, where it creates (F1
^bar ran) in parallel with the creation of (S1 ^foo F1). When these two are
created in the same rule, Soar is smart enough to look for the connection
between them, but since this is happening in rules firing in parallel, it is
not smart enough to examine all of the parallel actions (that create other
preferences) and notice that F1 is now in the closure of S1, so (F1 ^bar ran)
should be a result. As you can imagine, doing this right would require it to do
some extra processing (multiple passes through all of the preferences to chain
through dependencies) that I'm sure Soar isn't doing. So, yes it is a bug, ....
Original issue reported on code.google.com by marin...@gmail.com on 29 May 2013 at 6:15
Original issue reported on code.google.com by
marin...@gmail.com
on 29 May 2013 at 6:15Attachments: