First off, the Pronouns extension is great. This error, however, is odd, and I thought I’d report it. At present, I can’t see any way around it other than trap every instance that could give rise to the offending error - which I’m loath to do. But needs must.
Anyhow, to demonstrate:
Include Pronouns by Ron Newcomb.
Home is a room.
Corwin is a man in Home. The player is Corwin.
Fiona is a woman. Fiona is in Home.
Bleys is a man. Bleys is in Home.
Deirdre is a woman. Deirdre is in Home.
Brand is a man. Brand is in Home.
A garment is a kind of thing.
The sweater, the skirt, and the tie are garments.
A body part is a kind of thing.
A face and a nose are kinds of body part. A nose and a face are parts of every person.
Deirdre is wearing the sweater. Bleys is wearing the tie. Fiona is wearing the skirt.
Understand "your" as a thing when the item described is enclosed by the person asked.
Understand "my" as a thing when the item described is enclosed by player.
Understand "his" as a thing when the item described is enclosed by him.
Understand "her" as a thing when the item described is enclosed by her.
Definition: a person is other if it is not the player.
Rule for printing the name of a body part (called stuff) that is not other:
let x be indexed text;
let x be the printed name of stuff;
let y be indexed text;
let y be the printed name of player;
replace the regular expression "[y]'s" in x with "your";
say "[x]".
Test me with "x Bleys / x his face / x fiona's face / x her face / x her weeble / x her wooble / x his weeble / x his graaa".
It certainly looks like a bug to me (if you’re referring to the odd behaviour around ‘her’), and with Inform7 rather than the extension. I guess we should expect as much from IF code written by men.
Yes indeed, the problem seems to be with the internal pronouns - however, I wasn’t completely certain, so I thought I’d just report the circumstances involved. Linguistically, the word “her” does have a wider meaning than “his” or “its”, since you can say both “talk to her” and “talk to her parrot” with equal validity (while “talk to his” or “talk to its” is obviously incorrect).
This, sadly, demonstrated further problems of the buggy kind:
Home is a room.
Corwin is a man in Home. The player is Corwin.
Fiona is a woman. Bleys is a man. Fiona and Bleys are in Home.
A shirt is a kind of thing.
Fiona is wearing a shirt. Bleys is wearing a shirt.
Before examining a thing:
let x be the holder of the noun;
say "[printed name of x]".
Test me with "x shirt / x shirt / x his shirt / x shirt".
Now, add the following among the clothing declarations:
Corwin is wearing a shirt.
Evidently, the gender pronouns refuse to play nice with duplicates - “it” evidently means “any one iteration of the shirt,” and as far as I can tell the parser then goes by first player-worn, then female-worn, then finally male-worn. The problem is when similar clothes force the user to type “x john / x john’s shirt” because mary also wears a shirt - and unless the player knows to look at John before asking about “his” shirt, John’s shirt will be invisible.
I would really like it to disambiguate between duplicates when said duplicates are nearby. I think I can do it manually, but it comes across as setting myself up for nasty errors further down the line.
That is a pretty strange problem. The following (seemingly redundant) line takes care of the issue without introducing any immediately obvious side-effects:
Rule for printing a parser error when parser error is can't see it at the moment:
say "You can't see any such thing.".
On an unrelated note, if you’re going to be setting up any scenario where gender differences between characters are nontrivial, you’re better off throwing out Inform’s default treatment of such matters as it’s generally very confused and a source of endless frustrations. A simple step that will save you a lot of future headaches would be:
A human is a kind of animal.
A guy is a kind of human. A guy is always male. Understand "man" as a guy. Understand "men" as the plural of a guy.
A gal is a kind of human. A gal is always female. Understand "woman" as a gal. Understand "women" as the plural of a gal.
Awesome. Thank you; that does indeed fix the problem.
I think I was overly focused on the his-her dichotomy, or, in other words, how to make “his sweater” refer to a sweater worn by someone male (preferable the one listed by the pronoun “him”) rather than a woman (which it will cheerfully do, unless I’ve made a terrible mistake somewhere and it only happens on my system). I’ve regexed that behaviour away, laboriously, and I’ll continue to chip away at the code until it looks tolerable, but… the parser’s behaviour in that regard still bugs me.
Aha, interesting. I like that it formalizes things, but I think I’m missing the full implications. Which problems will that piece of code address?
I’m not sure what benefit this is supposed to provide. It basically duplicates the built-in man and woman kinds, which are defined like so:[code]The plural of man is men. The plural of woman is women.
A man is a kind of person.
The specification of man is “Represents a man or boy.”
A man is always male. A man is never neuter.
A woman is a kind of person.
The specification of woman is “Represents a woman or girl.”
A woman is always female. A woman is never neuter.[/code]
My comment was of a very general nature, and doesn’t address any particular aspect of the code discussed in this thread. Writing rules for either all or some beings under the default person/man/woman/animal system presents many technical difficulties and simple inconveniences, since these distinctions are very arbitrary, in my opinion are not very useful, and ignore the likelihood that members of the separate categories “man” and “woman” will have much more in common with each other than a member of either category will likely have in common with a member of the generic “person” or “animal” classes. I’ve also seen many cases where Inform gives nonsensical compiler errors when one attempts to write rules considering a person or animal’s gender*; in many contexts the program regards gender as a temporary state rather than a fixed characteristic unless one explicitly defines kinds which are then explicitly assigned a gender (e.g. A dog is a kind of animal. A boy-dog is a kind of dog. A girl-dog is a kind of dog. A boy-dog is always male. A girl-dog is always female).
I certainly didn’t intend to derail the thread with my side comment. As Eleas has had a few threads now directly or indirectly making reference to body parts, I was just noting in passing that there are many troubles particularly associated with attempting to make men and women with different sorts of body parts (for example, let’s say we’re talking about men whose heads have beards/mustaches vs women whose heads do not have beards/mustaches) then subsequently writing rules about either body parts in general or the particular body parts of men that that are not shared by women (or vice-versa) since men and women are different classes of beings under the default system. These troubles are further amplified if for example our game also includes cats, who have have completely different types of heads than either men or women. All such problems are eliminated, however, by combining “men” and “women” into one class (“human”) and then separating them as sub-kinds of the greater class; if one is working on a set of general rules rather than rules for a particular scenario, building in this sort of formalization from the start is much less frustrating than attempting to go back and add it in later after one has already written thousands of words of rules on the assumption that the default system would be adequate for all purposes.
*nope, I can’t produce any specific examples at the moment
Back on topic:
This always requires extra effort, but in general I would think you’d want to have some customization of items if for no other reason than to avoid monotony. For example rather than simply saying that John and Mary are both wearing shirts, I’d want to write that John is wearing a green t-shirt and Mary is wearing a silk blouse in which case it’s much easier for the player to refer to John’s shirt or Mary’s shirt. Although this is very subjective, as a player I wouldn’t try to refer to John’s outfit as “his shirt” rather than “green t-shirt” (leaving out any reference to John himself).
Though I’m not a mod, I have to say that as far as I’m concerned, I’ve yet to see you derailing anything. On the contrary your input is always useful, and given the levels of activity on the forum, it’s not like you’re hogging the microphone.
Yeah, I know; it’s understandable, and I was going to do that. Thing is, my exploration of the methods was intended to solve cases where something like that does not work. When you say “as a player”, you say that as a player presumably used to IF. I get that, and it’s fine. I also recall how, for the longest time, neither I nor my friends wanted any part of IFs. We never got into them, and the reason given was almost unanimous: it felt as if the parser was deliberately standing in our way and sabotaging our efforts (I later took up playing again after trying Galatea, which convinced me of the potential of IFs).
Heading into digression territory now, however, so I’ll put it under a spoiler tag:
[spoiler]I’m not trying to create a perfect parser, far from it. But to me, the pursuit of a limited vocabulary as the better alternative is a false dilemma. We don’t need to allow “fetch the waiter, telling him to prepare a light dinner and be quick about it” recognition; there are many simpler ways of allowing the player to influence the world without such contortions. That, however, shouldn’t be an excuse for “examine Joey’s face” failing because Joey is a synonym rather than proper name, or for “x her shoes” to instead (without telling us) causing the parser to examine her husband’s blood-soaked boots because “she’s” actually wearing “slippers”, pronouns be damned.
A grizzled IF player might accept this as established conventions. To a beginner or casual player, both examples are completely capricious; it’s only because you know how IFs are actually put together that you’re able to tell why you can examine “Joey” but not “Joey’s face”, or why two things that are shoes, one of which is worn by a woman, should default to the person we expressly used a pronoun to exclude (in a command which, lest we forget, was accepted by the parser).
In light of that, I feel I have no choice but to patch the system (clumsily, as learning I6 and C# at the same time has proven to be a strain) before I even dare to begin a project. I do that, of course, because I think Inform is a barrel of fun in many other respects. I’m just dissatisfied with its behaviour when it comes to winning the trust of players.
(I say “trust” because to me “mimesis” is incidental; immersion is in the eye of the beholder, and not really the issue at hand. Yes, acceptance of the illusion is a grand thing, but before that can be instilled in a player, basic faith in the system itself must exist. There’s a difference between reading a novel and wishing it were more atmospheric, and opening a book to find the pages falling out and/or inserted at random.)[/spoiler]
Returning to the topic, the list of what needs to be done has mutated. What I’m attempting right now is:
allowing “his” to reference to an object enclosed by a male person. Right now, it does not, in several respects.
causing “her” to reference to an object enclosed by any female person, and, if that object is not contained by any female person in scope, causing it to interpret the word as the pronoun she. Inform’s behaviour when it comes to the feminine pronouns appears somewhat broken.
allowing the disambiguation to accept responses to “Which suitcase, John’s or Mary’s” that lack the possessive and may consist of synonyms (“John” or “her” being perfectly reasonable responses that suffice to remove any ambiguity, i.e. the purpose of disambiguation)
Having the parser consider “(something)'s” as a reference to possessive by name or synonym, and altering (for instance) “lady’s coat” into “Miriam’s coat” when Miriam holds the reference “lady” and encloses the coat.
All of this I can and have done with regex. The code, however, is quite ugly. I’d rather find a better way, particularly since I dislike having to provide every person with a synonym text. But that’s the way it seems I have to go.
So there’s one thing right now I really need, to reduce some the amount of workarounds. I don’t even know if it can be done. But is there some way of making I6 to return the understood synonym words of a given object as text? If so, how?
