Trouble looking up relations related in groups

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).

1 Like

I’ve gotten around this by modifying the HASH_KOV task to return the long block address associated with the short block; this will be the same for both the original R and its local copy.

It seems to be working as intended now; I’ll report back if any undesirable side effects pop up.

EDIT: Added demonstration scenario for the problem above.

1 Like