SML Create*WME methods can break set property of working memory

[GoogleCodeExporter]

Normally, we consider working memory a set, such that any unique triple
(id, attribute, value) has only one instance. Apparently you can break this
property and create two identical wmes on the input link using any of the
Create(Int|Float|String)WME methods, and they actually behave in Soar as
two separate wmes with exactly the same values. I've made a test case that
demonstrates this.

Presumably this is bad as both Sam and I write agents that exploit the set
property.

Original issue reported on code.google.com by joseph...@gmail.com on 13 May 2010 at 2:55

Attachments:

• test.cpp

[GoogleCodeExporter]

This is a known issue, it has come up before. I'm having trouble finding where 
we've talked about it so I'll try to recall from memory. I think it is worth 
taking a fresh look at this.

I believe that the resolution was to not fix it because of a couple of issues:
 * It is possible but expensive to check for this during creation on the client side,
 * It is unclear how to gracefully fail and report the error if detected on the kernel-side. Obviously an option is to have the Create*WME method return null and report the error through Agent::GetLastError, however I'm not sure how easy this will be to implement through the connection layer. I'm sure it can be done.
 * I'm not sure how expensive this will be to check for on the kernel side, a clue that it might be expensive is the fact that the add-wme command doesn't check for it either.

So, instead of fixing it, I think the resolution was to leave it to the client 
program to keep track of what it is putting on the input link and to not 
violate the set. A fault with this is that the agent can add wmes to the input 
link that the client doesn't know about potentially causing the client to 
inadvertently violate the set.

I'm sure these things can be solved, I'm just trying to make clear that it 
might not be trivial.

Regarding add-wme:
1 (raw) test> add-wme s1 ^foo bar
Timetag: 13
1 (raw) test> add-wme s1 ^foo bar
Timetag: 14
1 (raw) test> print -i s1
(4: S1 ^epmem E1)
(14: S1 ^foo bar)
(13: S1 ^foo bar)
(10: S1 ^io I1)
(3: S1 ^reward-link R1)
(7: S1 ^smem S2)
(2: S1 ^superstate nil)
(1: S1 ^type state)

1 (raw) test>

Original comment by voigtjr@gmail.com on 16 Jun 2010 at 4:15

[GoogleCodeExporter]

It probably would be a little expensive to enforce (you'd have to grab the slot 
and iterate I think). It might be interesting to have a "debug/lint" mode or 
whatever that does the check. Kind of like the stack/heap consistency checks in 
Windows debug builds.

Original comment by dave...@gmail.com on 16 Jun 2010 at 5:48