Time to cheer up!

Hi!

So I was going to title this thread something like “Sorry for the vast amount of rudeness following!” as it’s all about something I noticed when trying to implement a “piss off” action in my WIP (so there was a lot of piss off this and piss off that!) but I found an alternative example to ilustrate the same issue (if it’s an issue at all!)

Imagine I’m trying to code a “cheer up” action in my Beta thing, something that would certainly have an effect on people, but not on things. Something like this:

[code]
Location_01 is a room. “You’re in Location_01.”.

A book is a thing in location_01

Rose is a woman in Location_01.

Cheering up is an action applying to one thing.
Understand “cheer [someone]” as cheering up.
Understand “cheer [someone] up” as cheering up.
Understand “cheer up [someone]” as cheering up.
Report cheering up: say “‘Hey, hey, hey! It’s cheering up time!’ you say, while [noun] stares at you with amazement.”

test me with “cheer/cheer up/cheer rose/cheer rose up/cheer up rose/cheer book/cheer book up/cheer up book”.[/code]

The test outputs this:

I expected [8] to be the same that [6] and [7], but that was not the case!
I took a look into cheer grammar lines in auto.inf. As expected, they were just like this:

Verb 'cheer' * creature -> A80_cheering_up * creature 'up' -> A80_cheering_up * 'up' creature -> A80_cheering_up

I tried doing the same in a plain Inform 6 project and “cheer up book” gave the expected response requiring an animate object (and not claiming the book was not in sight)

I’m aware that I could easily work it out creating a check rule of my own instead of just trusting the “someone” tokens to do the job. What I would like to know is whether that [8] output in the first test is right or perhaps something is not working as it should.

My answer is “probably”. The exact handling of rejected parser lines has shifted since the I6 days, but I don’t have a precise handle on how. This does not surprise me.

Even in the I6 days, best practice was to never use a conditional token (“creature” then, “[someone]” now) without adding a “noun” / “[something]” grammar line to catch everything else. Or, as you say, discriminate at the check level rather than the grammar level.

(I think the current behavior is cleaner, actually. The I6 “creature” token was a weird hybrid that would match non-creatures but generate an error. That’s more work than you really want a grammar line to do.)

FWIW, the reason behind the difference is that the priority of the parser errors has changed:Constant ANIMA_PE = 4; Constant CANTSEE_PE = 5; in Definitions.i6t (used by I7) vs. Constant CANTSEE_PE = 4; ! ... Constant ANIMA_PE = 11; in parserm.h (used by I6).

Ah, thanks.

… and thank you both for clarifying it up! :slight_smile: