Understand "[someone], [something]" as informing it about?

Authoring Inform 7
1

I’m sure this has been covered before, but I haven’t found it after a quick search.

Commas in player commands are treated at a low level by Inform, aren’t they? And they either parse as “orders” or as “answering it that.” I’m using Eric Eve’s Conversation Framework and I’d like, ideally, to parse ALL attempts at conversation as quizzing or informing. But I can’t figure out how to do this one.

I suppose I could use indexed text to rewrite the command, but I’d like to avoid indexed text if possible.

I thought I might be able to redirect the “answering it that” action just as it is done for “saying yes,” etc. Unfortunately, by the time I did that, it would be too late for disambiguation, which I’d still like to have.

I’m open to suggestions as to how to solve the problem before me, and I’m willing to accept “tell the player to rephrase their command” as advice if that’s the most reasonable solution. But I’d also like to hear about the current thinking on the parser, whether something like this could be implemented in an extension (or has already been), or whether it might be considered as a change to future versions of Inform.

2

A bare command (a command in which nobody is explicitly addressed) is understood by Inform as an order to the player. Therefore, >GO NORTH does the same as >YOURSELF, GO NORTH. So you don’t have do define commands with an [actor], [something] pattern.

Maybe the following example does what you have in mind:

[code]
The Kitchen is a room.

Bob is a man in the Kitchen.

The apple is an edible thing in the Kitchen.

Vaguely being informed about is an action applying to one thing.

Understand “[something]” as vaguely being informed about.

Check an actor vaguely being informed about:
if the actor is the player, say “You reassure yourself: yes, this is [a noun].”;
otherwise try telling the actor about.

Test me with “apple / bob, apple”.[/code]

3

That seems like a good idea, but it’s not working for me.

If you do “actions” before you run your example, you’ll see that the action is still “answering Bob that ‘apple’.”

The problem is that the comma is handled at a very low level in I6. I’m not sure how I7 handles grammar lines that don’t start with a command verb, but it seems that whatever mechanism is used for that doesn’t get to run before the line is parsed as ##Answer.

I’m thinking of writing an extension for “disambiguation on demand” so that the topic understood from the “Answering it that” action can be reparsed as an object and then used in the informing it about action. But it’s a lot of work to solve one specific problem. At this point I’m considering writing an extension to replace this I6 hack with a routine that can handle commas in a more general way.

4

If you’re re-defining the “person, stuff” syntax completely, then wouldn’t a Persuasion rule that tries the informing it about action work?

As for topics to objects, if the parser doesn’t understand the latter part of “person, stuff” then it won’t understand “stuff” by itself either. The answering it that action is just a parser error by another name.

I guess I’m confused about what you’re aiming at.

5

I’m not sure if you’re talking about rewriting Parser Letter H, or just modifying the example here, but I tried the latter. Adding a persuasion rule doesn’t seem to make any difference:

[spoiler][code]The Kitchen is a room.

Bob is a man in the Kitchen.

The apple is an edible thing in the Kitchen.

Vaguely being informed about is an action applying to one thing.

Understand “[something]” as vaguely being informed about.

Persuasion rule for asking someone to try vaguely being informed about something:
Persuasion succeeds.

Check an actor vaguely being informed about something:
say “‘That’s nice.’”

Instead of Bob trying vaguely being informed about the apple:
say “‘That’s a delicious-looking apple,’ says Bob.”

Test me with “bob, apple”.[/code][/spoiler]

And parser errors are what the “disambiguation on demand” extension is all about - part of my idea for iterative parsing. This is what I’d like to have happen here:

Instead of answering someone that something when the topic understood matches "[any known thing]": Let the item understood be the topic understood as an object; if the item understood is not nothing, try informing the noun about the item understood.

The extension would define a “to decide which object is (topic - a snippet) as an object” phrase which performs disambiguation if necessary.

I’m a little fuzzy on what would happen if the player entered a new command instead of answering the “which do you mean” question - I’m imagining that the turn sequence would abort and start over again at the beginning, but that might be dangerous. I haven’t yet reviewed the behavior of similar question-and-answer interactions such as “if the player consents” and the various question-handling extensions.

6

Ah, I misunderstood. Well then I would’ve suggested what ChristianB already did, but why that doesn’t work, I don’t know.

It’s clunky, but in Answering It That, you can use regexes on the player’s command to remove the person being addressed, stow the actor variable in a informed-actor variable, finish the action, skip parsing the 2nd time with Rule for reading a command when the command to re-try is not empty: change the text of the player’s command to the command to re-try; now the command to re-try is “”., then use a Before on the Informed-actor being something to try your new action.

You might want to file a bug on Christian’s example.

7

Like this, assuming you have a current interlocutor variable.

[code]The command to re-try is indexed text that varies. The command to re-try is usually “”.

Rule for reading a command when the command to re-try is not “”:
change the text of the player’s command to the command to re-try;
now the command to re-try is “”.

Check answering when the player’s command matches the text “,” :
now the current interlocutor is the noun;
now the command to re-try is the player’s command;
replace the regular expression “^<^,>+, *” in the command to re-try with “”;
rule succeeds.[/code]

8

That seems to work, Ron - thanks!

I was starting to get the impression from compiler errors that you couldn’t match a comma anywhere, but that one is okay.

Still, I’m going to work on doing it without indexed text. Maybe I can come up with a safe I6 routine for modifying the buffer? buffer2’s not used after disambiguation is done, is it?

9

I honestly do not know. Jon & Aaron have tinkered with the parser more than I. I just know how to get I7 to use what’s already there, and I obviously don’t care enough to optimize away indexed text. Long live Glulx, and all that.

10

The parser converts “Bob, apple” and the like to the answering it that action at Parser Letter H in the Parser Template.

Shouldn’t it be possible to tell Inform that

The informing it about action translates into I6 as "Inform".

and then replace the line
parser_results–>ACTION_PRES = ##Answer
in Parser Letter H with

parser_results-->ACTION_PRES = ##Inform

?

(Haven’t tried it out, though …)

11

I filed it:

inform7.com/mantis/view.php?id=526