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.