Pronoun Understanding Error

Ok, so this one is likely to result in someone telling me I shouldn’t be doing what I’m doing in the first place, but here goes. If you want an explanation of why I’m doing what I’m doing, look at the specification of a person in the following code.

My question about this is that when doing this, I’m getting a parser error indicating that the parser isn’t able to understand the i6 pronoun “him” anymore when it is defined for new understanding phrases.

Note that the below is the “minimum” necessary to reproduce the result, and I’m already making headway into masking each kind of thing so that what is presented in the output and interactions of objects doesn’t have weird results like “the woman is empty” etc. I wasn’t going to paste my entire project here, but it took quite a bit of code pasted here to provide a working small “game” to reproduce the problem.

Here it is:

Section 1 - Every Thing is a Prop_Object - Even People (in place of Section SR1/11 - People in Standard Rules by Graham Nelson)

A device is a kind of person.
A container is a kind of device.
A supporter is a kind of container. 
A prop_object is a kind of supporter.

After reading a command:
	if the player's command matches the regular expression "(?i)_object":
		say "Cheating is not allowed. If you actually see the text '_object' in the game, please report this as a bug to the author.";
		reject the player's command;

A prop_object is always privately-named.

[The specification of person is "Despite the name, not necessarily
a human being, but anything animate enough to envisage having a
conversation with, or bartering with."']

The specification of a person is "Everything is a person and everything is a prop_object.
This is because kinds cannot be changed, but we want the ability 
for a person to masquerade as or actually transmogrify into other forms,
as well as for non-living things to do the same in becoming other 'kinds' of things.
Doing this by swapping out things for other things is no good, it really just isn't,
this has been tested and prototyped to death for a year, and it is just no good. 
Only by eliminating the actual use of 'kinds' by making everything the same
kind can objects actually be changed from one 'kind' to another
through definining 'kinds' via a system of properties and rules instead. 
A great deal of the Standard Rules have to be reinvented to enable this.".

A person can be female or male.
A person can be neuter. A person is usually neuter.
A prop_object can be lifeform_enabled. A prop_object is usually not lifeform_enabled.

A category is a kind of value. generic_category is a category. A prop_object has a category. Understand the category property as describing a prop_object.

feminine_category is a category. masculine_category is a category. androgynous_category is a category.

Rule for printing the name of a prop_object when the item described is feminine_category:
	say "woman";

Understand "her" as a prop_object when the item described is feminine_category.

Rule for printing the name of a prop_object when the item described is masculine_category:
	say "man";

Understand "him" as a prop_object when the item described is masculine_category.

A person has a number called carrying capacity.
The carrying capacity of a person is usually 100.

Include (-
	has transparent animate
	with before NULL,
-) when defining a prop_object.

The yourself is an undescribed androgynous_category prop_object. The yourself is proper-named.

The yourself is privately-named.
Understand "your former self" or "my former self" or "former self" or
	"former" as yourself when the player is not yourself.

The description of yourself is usually "Placeholder."

The yourself object translates into I6 as "selfobj".
Include (-
	with saved_short_name (+ "yourself" +),
 -) when defining yourself.

The prop-room is a room.

100 prop_objects are in the prop-room.

Section 2 - Every Thing is a Prop_Object - Even People - Continued (in place of Section SR2/1 - Situation in Standard Rules by Graham Nelson)

The player is a prop_object that varies. [*]
The player variable translates into I6 as "player".

The location -- documented at var_location -- is an object that varies. [*]
The score -- documented at var_score -- is a number that varies.
The last notified score is a number that varies.
The maximum score is a number that varies. [*]
The turn count is a number that varies.
The time of day -- documented at var_time -- is a time that varies. [*]
The darkness witnessed is a truth state that varies.

The location variable translates into I6 as "real_location".
The score variable translates into I6 as "score".
The last notified score variable translates into I6 as "last_score".
The maximum score variable translates into I6 as "MAX_SCORE".
The turn count variable translates into I6 as "turns".
The time of day variable translates into I6 as "the_time".

Section - 3 The Test Game

The kitchen is a room.

The player is in the kitchen.

A Bob is a masculine_category prop_object in the kitchen.

A Sally is a feminine_category prop_object in the kitchen.

Note that I can target Sally with “her”, but I cannot target Bob with “him”.

I’ve been able to circumvent this problem with a kludgy workaround, but I’m still interested in why the pronoun stopped working. I also wonder what else might crop up as I work through this…

Understand "he" as a prop_object when the item described is masculine_category.

After reading a command when the player's command includes "him":
	replace the matched text with "he";

I’m going to look more thoroughly a your code now, but you’ll run into lots of problems later if you move all the I6 property declarations from individual kinds to “prop_object”. For example, containers are defined with “has container” and supporters with “has supporter”, but an object can’t have both of those at the same time. The code here makes every “prop_object” animate and transparent, so the game won’t notice if the player tries to give orders to a wall. And the pronoun system is more complex than these Understand lines. You probably want

[code]>X BOB
Bob is a man.

You hit Bob.[/code]
rather than

[code]>X BOB
Bob is a man.

Which do you mean, Al, Bob, Charles, or Dave?[/code]

If you’re going to be using a single type of prop for everything (rather than a set of container props, a set of person props, etc.), you will need to use some I6 to make sure all the low-level properties get set and restored correctly.

If the only use case is the one you outlined above, where you can’t keep the focus on a pronoun, I could very much live with that. It sounds like there’s a bunch of other gremlins lurking around then.

So, my brain has been spinning on this then… basically, the problem is that these base kinds are indeed not able to change from one to the other, but my intent is to have shape shifting and transmogrification and other similar effects in the game, and for those to be non-scripted, but more open-ended. If it’s on rails, this is easy enough to do by swapping objects with specific rules, but if virtually anything can become virtually anything, having the potential object to swap out for is going to result in a nightmare for coding and tens of thousands of objects…

I know my original question in this post was about pronouns, but this is the root cause so… what if instead of doing what I’m doing above, I made every thing simply be a person, and then made a device, supporter and container a part of every person, as in “Mimic’s_container_object is a container that is part of Mimic_object”. Then, have a universal rule for something like the psuedocode “Before opening a person when the item described is container_enabled: try the actor opening the container that is a part of the item described”… etc.

Any horrific caveats to that high-level approach?