Want gamma-testing for new I7 extension: Gender Options

So, I’ve been trying to develop a game – and I’m not sure the game will ever get finished because I’ve had more fun developing extensions!

Anyway, the first extension I’ve spawned is a conceptually simple one:

It treats male, female, and neuter as three separate on/off flags, handles the he/she/it typed by the player accordingly, and provides global flags for picking a preferred pronoun for things which have more than one of these characteristics. This solves a number of long-time parser irritations for me (why can’t I call the dog both “he” and “it”, why can’t I call the ship both “she” and “it”, why can’t I call a character of undetermined gender both “he” and “she”).

If you use “man” or “woman” without explicitly referring to “male”, “female”, or “neuter”, you should see completely unchanged behavior (and this is also something I want tested).

Under the hood, it’s actually pretty complicated; I have to replace substantial hunks of the Standard Rules and of the I6 library. I would actually argue that these changes should be part of the standard release, but that gets released very infrequently.

Anyway, I think this is probably ready to send to the extensions public library. But I’d like to get some outside feedback first, to see if there’s anything which should be polished. Features are locked and I think I’ve solved the corner cases, so I’m requesting gamma testing rather than beta testing. Nitpicky corrections to typos in the documentation are welcome. :smiley:

I’ve got about four more extensions in the works, several of which are updates/replacements for other people’s extensions which were broken by 6L02, 6L38, or 6M62. For now, please ignore the references to Neutral Standard Responses; it’s not ready for release yet.
Gender Options.i7x (38.9 KB)

Does this allow objects to take singular verbs with their name, but plural verbs with a pronoun? (For example, “The shadowy figure walks closer. They look angry.”) That’s something I’ve been wondering about for a while, but it’s not easy to implement in I7.

2 Likes

No. You piqued my interest, however, and I see how to do it. This is very much a “next major version” thing, though.

The reason it doesn’t do it directly is:
(a) I was much more focused on processing the player’s input than on output processing. (The player can refer to the shadow as “it” or “they”.) This was my priority because it’s already possible for the game writer to tweak the output text manually without replacing parts of the Standard Rules, writing I6 code, or replacing parts of the I6 templates – all of which you need to do to let the player refer to the shadow as “it” or “they”.

I actually only dealt with the output at all because broadening the gender treatment promptly broke the output code, which immediately started behaving inconsistently and with undesirable defaults. (The Standard Rules algorithm and the Plurality algorithm are not the same for multi-gendered things.) I didn’t want random changes of “him” or “her” printing depending on which extensions were included or which version of Inform was used, so I had to patch it up just to get reliable behavior and reasonable defaults.

(b) I was more focused on the gender treatment than the singular/plural treatment, and fixing the plurals is harder. (There are four additional spots in I6 code which check plurals.)

© I had to limit the scope of the extension. It’s tempting to code full custom pronouns. (I think someone already did that for an earlier version of Inform 7, which I might update sometime, but I seem to have lost the link.) But that’s a much larger job, particularly due to the ugly bit-twiddling which Inform 6 code does when checking pronouns; an even larger expanse of Inform 6 code would need to be interfered with and it might actually slow the game down due to being frequently-checked higher-level code. This extension should be just as fast as the standard version since it’s implemented at the same level in essentially the same way.

So by default we get “The shadowy figure walks closer. It looks angry.”

You roused my curiosity, though. So for a first try, I whipped up this code:

"Lurking Shadow"

Include Gender Options by Nathanael Nerode.
City Park is a room.
The description of City Park is "Everyone comes to City Park!"

to lurk is a verb.

to say pluralize (x - a thing): now x is plural-named.
to say singularize (x - a thing): now x is singular-named.

The shadow is a person in the park. "Someone skulks in the shadow."
The shadow is ambiguously plural.
The shadow is neuter.
Understand "skulker" as the shadow.
The description of the shadow is "[singularize the shadow][The shadow] [lurk].  [pluralize the shadow][They] [look] angry.[singularize the shadow]".

This works extremely reliably, but may be painful if you are writing a whole lot of descriptions. Read onward for an alternate solution.

I wish someone would fix the bug which causes gnome-inform7 to crash intermittently… really slows down the testing cycle…

I did a whole lot of additional digging and now have some substantial updated comments in Gender Options, though I haven’t changed any of the code. I discovered a subroutine used by the autogenerated verb conjugation code, PNToVP, which calls GetGNAOfObject on the prior named object.

As far as I am concerned GetGNAOfObject is deprecated and should not be used. GetGNAOfObject is bypassed by most of my code because its return value protocol doesn’t allow for multiple genders. All but one of the remaining calls are only checking for plurals, and should be replaced with a subroutine which only checks for plural naming, which would then be much easier to patch.

(The final call which still reads gender from it is only for disambiguation in the parser, and is the lowest priority disambiguator, so I decided it was unimportant. I know how to patch it but it requires replacing three pages of parser code to change one line.)

Anyway, the underlying problem you’re encountering is that PNToVP, which decides whether to add the “s” on the verb, lacks context in that it doesn’t know that “[they]” was just used rather than “[the object]”: its only contexts are is the prior named object… and the prior named list. It’s too dangerous to alter the prior named object… but this suggests a trick, by altering the prior named list.

"Lurking Shadow"

Include Gender Options by Nathanael Nerode.
City Park is a room.
The description of City Park is "Everyone comes to City Park!"

to lurk is a verb.

[For hackery]
The prior named list count is an number that varies.
The prior named list count variable translates into I6 as "prior_named_list".

to say They:
	let the item be the prior named object;
	if the prior naming context is plural:
		say "They";
	otherwise if the item is the player:
		say "[We]";
	otherwise if the item is ambiguously plural:
		say "They";
		now the prior named list count is 2; [complete rotten hack]
	otherwise:
		if printing gender for the item is:
			-- the masculine gender: say "He";
			-- the feminine gender: say "She";
			-- the neuter gender: say "It";

The shadow is a person in the park. "Someone skulks in the shadow."
The shadow is neuter.
The shadow is ambiguously plural.
Understand "skulker" as the shadow.
The description of the shadow is "[The shadow] [lurk].  [They] [look] angry.".

Sure enough, this works. (The definition of “They” in the game overrides the definitions from extensions.) But it could cause some weird effects. I’m not sure whether there are any ill effects to my egregious hacking of the prior named list count, so I’d rather reserve that for the next major version.

Also, I’m not sure whether to switch this off of ambiguously plural (I think probably not; I suspect I need a new flag). Does it make sense for all ambiguously plural nouns to use a plural printing gender (i.e. “the pair of dice” should always be “them”) or do I need an additional switch because some of them shouldn’t? I suspect I need an additional switch; anyone have any examples where the item should be referred to as “she” and “them” but should print as “she”?

If you like, you can do a
Section - Further pronouns with number-changing they (in place of Section 3 - Further pronouns in Gender Options by Nathanael Nerode)
Which is basically what I did in Gender Options once I realized I had to replace everything in the section. You might have to replace the “We” section as well.

Anyway, now you know two different approaches to do it in your own code without I6 hacking (apart from exposing “prior_named_list” in the second version).

This is something I might add to the next version (a) if it proves reliable enough and (b) if I can resolve the design question of what to switch this behavior based on. I suspect I need a new flag.

Modern English quite definitely has a fourth grammatical gender, represented by the singular animate “they” (and distinct from the plural, which in some dialects is starting to become “they-all”) though it hasn’t been acknowledged by most grammarians yet. I may have to implement it.

Thanks for the question, it led me down an interesting rabbit hole.

Revised version already, in response to a use case I hadn’t thought of… (https://intfiction.org/t/making-the-pronoun-it-apply-to-the-last-noun-examined/11589/1) This doesn’t change the core behavior, it just changes the “syntactic sugar” portions. And rewrites a lot of the documentation.
Gender Options.i7x (42.9 KB)

I just noticed that this was a 2011 feature request.

https://intfiction.org/t/changing-gender-rules/1938/1

Well, better late than never, I guess! :smiley:

Haven’t tried to run this yet, but I noticed this from the documentation:

“If you want to make Tracey a man” should be “If you want to make Tracy a woman,” shouldn’t it? Also the word “androgynous” seems misleading there if I understand it aright–you mean “both male and female,” right? Honestly I think the clearest way to convey that is just “both male and female.”

1 Like

Thank you very much for the documentation corrections! :slight_smile: :slight_smile:

I like writing documentation, but I find it hard to spot errors in it – there’s a “see what you expect to see” problem. With code, the computer will tell you you’ve got it wrong. Not so with documentation.

I made some additional rewrites to documentation (behavior is same as version 3, which is slightly different from version 2).
Gender Options.i7x (43.2 KB)

And it’s now up on github in my clone repository.

I am not sure if it is better to raise a post from this long ago or start a new topic, but I’m directly trying to do what is in this topic but having difficulties. I would like to be able to change the pronouns for a person during runtime, and tried installing this extension to help. It isn’t working as I would hope given what I have below. It seems like once a pronoun is added, it remains viable even when the property is changed so that it shouldn’t seem to. In other words, once a person is “male”, “him” continues to work to refer to that object even if later it is made “not male” and “female” and vice versa, as if the pronouns are only additive and cannot be subtracted later.

Include Gender Options by Nathanael Nerode.

The starting room is a room.

The player is in the starting room. The player is not female. The player is not neuter.

Alex is a person. Alex is not male. Alex is not female.

Alex is in the starting room.

Feminizing is an action applying to one thing.

Masculinizing is an action applying to one thing.

Neuterizing is an action applying to one thing.

Understand "feminize [person]" as feminizing.

Understand "masculinize [person]" as masculinizing.

Understand "neuter [person]" as neuterizing.

Carry out feminizing:
	now the noun is not neuter;
	now the noun is not male;
	now the noun is female;
	set pronouns from the noun;

Carry out masculinizing:
	now the noun is not neuter;
	now the noun is not female;
	now the noun is male;
	set pronouns from the noun;	
	
Carry out neuterizing:
	now the noun is neuter;
	now the noun is not female;
	now the noun is not male;
	set pronouns from the noun;	

Sanity checking is an action applying to nothing.

Understand "sanity check" as sanity checking.

Carry out sanity checking:
	repeat with x running through people:
		say "Checking [x].";
		if x is male:
			say "[x] is male.";
		if x is female:
			say "[x] is female.";
		if x is neuter:
			say "[x] is neuter.";

And the results:

starting room
You can see Alex here.

>sanity check
Checking yourself.
yourself is male.
Checking Alex.

>look her
I'm not sure what 'her' refers to.

>look him
I'm not sure what 'him' refers to.

>look it
I'm not sure what 'it' refers to.

>look alex
You see nothing special about Alex.

>masculinize alex
>sanity check
Checking yourself.
yourself is male.
Checking Alex.
Alex is male.

>look him
You see nothing special about Alex.

>feminize alex
>sanity check
Checking yourself.
yourself is male.
Checking Alex.
Alex is female.

>look him
You see nothing special about Alex.

>look her
You see nothing special about Alex.

>look it
I'm not sure what 'it' refers to.

>neuter alex
>sanity check
Checking yourself.
yourself is male.
Checking Alex.
Alex is neuter.

>look him
You see nothing special about Alex.

>look her
You see nothing special about Alex.

>look it
You see nothing special about Alex.
>
1 Like

You’re right – “set pronouns from the noun” doesn’t attempt to unset any existing pronouns that refer to the noun. This change to Gender Options ameliorates the immediate problem. But this is just me fooling around – I don’t actually know Inform 6 or have any business futzing with the guts of the I6 Template layer and I don’t recommend really using this.

This just unsets the former pronoun. It strikes me that better behavior would be to look for the most contextually appropriate candidate and assign that. But to do that well, you might want to maintain a history of recent antecedent values and that’d be a can of worms.


[ PronounNotice obj x bm;
    if (obj == player) return;

        bm = GetGNABitfield(obj);  ! This is the change made by Gender Options by Nathanael Nerode.
    for (x=1 : x < (LanguagePronouns-->0 - 2) : x=x+3)
! this is the test I added
        if ((bm & (LanguagePronouns-->(x+1)) == 0) && (LanguagePronouns-->(x+2) == obj))
           LanguagePronouns-->(x+2) = NULL;
        else {
! the original had only this part
             if (bm & (LanguagePronouns-->(x+1)) ~= 0)
                LanguagePronouns-->(x+2) = obj;
             }
];

This gets us:

>sanity check
Checking yourself.
yourself is male.
Checking Alex.

>look her
I'm not sure what 'her' refers to.

>look him
I'm not sure what 'him' refers to.

>look it
I'm not sure what 'it' refers to.

>look alex
You see nothing special about Alex.

>masculinize alex
>sanity check
Checking yourself.
yourself is male.
Checking Alex.
Alex is male.

>look him
You see nothing special about Alex.

>feminize alex
>sanity check
Checking yourself.
yourself is male.
Checking Alex.
Alex is female.

>look him
I'm not sure what 'him' refers to.

>look it
I'm not sure what 'it' refers to.

>look her
You see nothing special about Alex.

>neuter alex
>sanity check
Checking yourself.
yourself is male.
Checking Alex.
Alex is neuter.

>look him
I'm not sure what 'him' refers to.

>look her
I'm not sure what 'her' refers to.

>look it
You see nothing special about Alex.

Thank you for working on that. I didn’t realize it would require “heavy lifting” coding/recoding. I don’t know any Inform 6, and just like to fiddle around with Inform 7 from time to time. I guess I wasn’t doing something “wrong” per se, but that the core engine, including the extension, were not designed to do this normally. Thanks for this!

I have been away from Inform for a long time; this is all correct, and Zed’s solution will work.

I actually made a conscious decision on this one. The meaning of “set pronouns from” is to set what “him”, “her”, and/or “it” refer to, and not to unset them.

As currently implemented, the player will be able to refer to Alex as “him” until the player looks at a different male object, and then won’t any more. The gender is gone, it’s just that “him” hasn’t been reassigned to anything else yet. (There are contexts in which this might be the desirable outcome; with something changing from “it” to “him” it follows the principle of least surprise for the player, IMO.)

If I were writing Gender Options now I’d probably implement a separate “clear pronouns from” I7 phrase, to maintain maximum flexibility. I can think of other reasons to blank out the pronoun referents, and they usually start the game blank. I definitely don’t want to maintain a list of recent antecedent values!

If I adapt Gender Options to Inform version 10 I will do something along these lines.


This is now done in the revised version of Gender Options and no0oneman’s test case was adapted as a new example in the documentation. “unset pronouns from Alex” is used to make sure there are no stale pronouns referring to Alex; I realize this is a little finicky, but I err on the side of flexibility.