I ran into something that took me a while to track down, and I want to see if anyone else has any input on solving it. I found this problem in 6M62, but the underlying issue still seems to apply in 10.1.2.
Demonstration Scenario
"Equivalence Relation Problem"
Place is a room.
Alice is a woman.
Bob is a man.
Carl is a man.
Dana is a woman.
Favor relates various people to various people. The verb to like means the favor relation.
Admiration relates various people to various people. The verb to admire means the admiration relation.
Alice likes Dana and Bob.
Bob likes Carl and Dana.
Carl likes Alice, Bob and Dana.
Alice admires Carl.
Bob admires Alice.
Dana admires Bob and Carl.
Particularity relates (relations of things) to each other in groups. The verb to be particular about means the particularity relation.
The favor relation is particular about the admiration relation.
[problems with list-building can disappear sporadically as scenario changes due to coincidences in changing memory locations and their associated hash values]
When play begins:
let favor-targets be the list of (relations of things to things) that relate to the favor relation by the particularity relation;
showme favor-targets; [shows only favor relation, not admiration relation]
let admiration-targets be the list of (relations of things to things) to which the admiration relation relates by the particularity relation;
showme admiration-targets; [shows only admiration relation, not favor relation]
Test me with "relations". [shows that particularity relation data store is correct]
I’ve created a relation along the lines of:
Particularity relates (relations of things) to each other in groups.
and a phrase along the lines of:
To frobulate (R - relation of values of kind K to values of kind L) ...:
...
let targets be the list of relations of Ks to Ls that relate to R by the particularity relation;
...
The targets
list was only being built correctly in a non-deterministic manner. I finally traced the problem to the way that the frobulate
phrase was being translated into I6:
tmp_0 = I7SFRAME; ! R argument
BlkValueCopy(tmp_0, RelationTest(Rel_Record_77, RELS_LOOKUP_ALL_Y, BlkValueCopy((I7SFRAME+WORDSIZE), t_0), (I7SFRAME+WORDSIZE*2))); ! builds list
It turns out that the phrase is doing a “pass by value” for the input relation and is setting up a copy of it on the heap. As a consequence, there is a problem due to the way that the HASH_KOV
task is handled for relations:
[ RELATION_TY_Support task arg1 arg2 arg3;
switch(task) {
...
HASH_KOVS: return arg1;
...
}
...
];
When the RELS_LOOKUP_ALL_Y
task requests a hash value for the relation R
, it uses the memory address of the short block, and this is echoed back without modification by the HASH_KOVS
task. When a pass by value has occurred while setting up R
, the memory address held by tmp_0
will be somewhere on the heap and bear no relation to the address of the source relation R
’s “home address” (i.e. its Rel_Record_NN
address).