Adjectives being confused with a noun

Here’s a slightly less hacky approach that achieves similar ends, with the caveat that attempts to refer to the object by adjective(s) alone will now by default lead to a curt rejection by the parser: ‘You can’t see any such thing.’ because adjectives alone no longer refer to any object. That does however neatly sidestep the issue of sole-adjective disambiguation:

The juice is a thing in the Lab with printed name "delicious glass of fresh orange juice".

Understand "delicious/glass/of/fresh/orange/--" as "[juice-adjective]".
Understand "[juice-adjective] [juice-adjective] [juice-adjective] [juice-adjective] [juice-adjective]" as "[juice-adjectives]".
Understand "[juice-adjectives] juice" as the juice.

Here Understand "[juice-adjective] [juice-adjective] [juice-adjective] [juice-adjective] [juice-adjective]" as "[juice-adjectives]" means ‘recognise between 0 and 5 repeats in any order of any of the juice-adjective words as being represented by the token [juice-adjectives]’, so Understand "[juice-adjectives] juice" as the juice. means ‘recognise the word juice preceded by 0-5 of its adjectives as referring to the juice object’

A slightly different perspective is that it’s like the joke about a man who goes to the doctor and complains that his thumb hurts, whereupon the doctor suggests he stops hitting it with a hammer. Or the man who tells an (English) magistrate that he needed his unlicensed gun to defend himself against bears… but barring escapees from zoos, there are no bears in England. :slight_smile:

adjective-noun / noun-adjective confusions that are genuinely likely to come up in practice are quite difficult to think up. So far I don’t think we’ve hit on one, although doubtless there is at least one out there!

2 Likes

I think this situation is more like the latter, because:

This. If I come across a game and realize at some point that I’m expected to type “Ask whale killer about killer whales,” my next command is most likely to be “quit.”

Having said that, it is nice to see proposed solutions for these edge cases should they ever become necessary in particular works. However, any notion that this functionality should be included in a “newly-improved” parser is, IMHO, unwise.

2 Likes

Currently replaying Zork Zero, thirty years after the first time. Its “new parser” doesn’t allow referring to nouns by an adjective alone, so, say, OPEN LOUVERED to open the small louvered door won’t work. ([Sorry, but I don’t understand. Please say that another way, or try something else.]) This is actually very annoying.

1 Like

Thanks, that’s interesting, looks like they “fixed” it. :slight_smile:

To illustrate my point with this;

I understand why people would want an adjective to identify an object for convenience, but my real point here is that any such identification should be a second class one and not a first class one.

What do i mean by this?

It should never be the case that the word “orange” identifies the “orange juice” when there is also an “orange” (the fruit) in scope. Right now, this prompts;

>look at the orange
Which do you mean, the orange juice or the big orange?

This is simply wrong. It should never do this. Yes, i know as many have pointed out this can be “fixed up” with a bunch of “understand” statements (and others).

But that should not be necessary. And the problem for authoring is that you might not immediately be aware that two objects with an overlapping adjective reference might be in scope at the same time. Which is a pain.

So here “orange” is a first class reference since it stands equal as an identify whether it references the noun or the adjective.

A second class reference would allow adjectives to identify an object only when there was not otherwise an ambiguity. As a kind of “back-up” and “convenient” way to save typing, this would be acceptable.

This makes sense, but aren’t the alternatives when there’s an ambiguity like this basically 1) the status quo, where the author notices the issue and manually fixes it with understand or DTPM statements; 2) create a new first order vs second order referent structure within Inform and require the author to manually define which are which whenever they notice an issue; 3) create a new first order vs second order referent structure in Inform and create algorithms to help it automatically figure out which should apply to each piece of a multi-word object name, requiring the author to manually tweak it when it inevitably gets messed up by “attorney general” or “Her Royal Highness Queen Flora the Third”.

Even leaving aside the work required to upgrade Inform in scenarios two and three, I guess I’m not seeing how these would be easier on authors than scenario one — if the algorithm works well in scenario three, I guess that would be easier, but I’m pretty skeptical that such a thing would work well, and requiring authors to learn a new bit of functionality vs just applying the same understand and DTPM tools they already have to use doesn’t necessarily seem like a helpful trade. Is there something I’m missing?

EDIT: just to restate this a different way, I agree this is definitely annoying! It’s just that every other way of solving the problem seems like it’d be differently annoying.

3 Likes

That is correct.

As I said, in I6 you could – with some effort – do a trick in the objects’ parse_name routine:

  • For the killer-whale: If both words “killer” and “whale” appear in the input, reject them if “whale” appears before “killer”. (But accept either separately.)
  • For the whale-killer: Same, but other way around.

This improves the situation markedly. “X KILLER” still generates a disambiguation question, but “X WHALE KILLER” always does the right thing.

(Handling the disambig question is harder, but I won’t get into that!)

If you want to improve things further, you could do an additional trick:

  • For the killer-whale: if the word “whale” appears but not “killer”, set a flag. Use this flag at ChooseObjects() time to give the killer-whale a bonus. (ChooseObjects() is the I6 equivalent of DTPM.)
  • For the whale-killer: Same, but other way around.

Now “X KILLER” will select the whale-killer if both objects are in scope, but will work for either if only one is in scope.

But, again, I7 pretty well locks out this entire line of enquiry. The I7 “bag of words or phrases” model is simpler for the author, but you can’t dig down to the level of word-ordering.

(Unless you apply regexes to the entire input, which puts you into another whole realm of hell.)

1 Like

Yeah, the best solution I can think of would be a fundamental change to the Inform compiler: allow syntax like Understand “orange” as modifying the orange juice which would put it into a special adj_name or adj_parse_name property (and remove it from the normal one). During parsing, first check against name and parse_name; if those don’t match, check against adj_name and adj_parse_name, and if those do match, set workflag. Then have ScoreMatchL prefer objects that don’t have workflag set over ones that do.

Since this requires a change to the syntax of the language, it’s not something end users can really do. The way Understand lines work is too deeply hard-wired into the compiler; the best we can do without a language change is to attach those Understand lines to different objects.

1 Like

The more general problem is that you have to customize objects in pairs (or really in groups). For both of the tricks I listed, you’re tweaking the whale-killer and killer-whale objects to not conflict with each other.

This is against Inform’s whole line of attack, where you’re supposed to be able to create one object without thinking about the entire rest of the game. Of course you can’t get away from that entirely, but the easiest advice for authors is “look, just don’t do that”. Don’t have objects whose names collide! Any more subtle approach is loading extra work onto the author no matter what.

2 Likes