[General] IF parsers

186 views
Skip to first unread message

Krister Fundin

unread,
Oct 13, 2006, 3:26:39 PM10/13/06
to
I've been working for a while on an extension to improve the English
parser in one of the popular IF systems, adding some things that I've been
missing in existing parsers, or which might be appreciated by newbies, or
which are completely useless but rather amusing anyway, like archaisms
and slang.

Having implemented much of what I could come up with on my own, I was
wondering if anyone else had any ideas: something you've always thought
that IF parsers should be able to understand or be smarter about, or
some issue that often shows up and deserves a general solution, or just
about any wild idea for that matter. All comments are welcome.

-- Krister Fundin

Neil Cerutti

unread,
Oct 13, 2006, 3:46:37 PM10/13/06
to

Most IF parsers cannot cope if you use any words that it doesn't
already know. This makes it impossible to generate actions with
unknown objects, and usually the parser resorts to saying:

If it is truthful: I don't know the word "humbug".
If it is Inform: You can't see any such thing.

It might be nice to permit the generation of actions with one or
more unknown objects and let the author try to sort things out
based on the text. Much better error messages could be one
result. Another nice result would be that writing grammar to
handle arbitrary conversation would become possible without doing
all of the work yourself, and without the need to create special
grammar tokens to gobble up arbitrary text.

It would be an unforunate nuisance if authors were required to
check for this special case in all action handling code, so the
interface would need to be constructed carefully.

--
Neil Cerutti

quic...@quickfur.ath.cx

unread,
Oct 13, 2006, 4:25:56 PM10/13/06
to
On Fri, Oct 13, 2006 at 07:26:39PM +0000, Krister Fundin wrote:
> I've been working for a while on an extension to improve the English
> parser in one of the popular IF systems, adding some things that I've
> been missing in existing parsers, or which might be appreciated by
> newbies, or which are completely useless but rather amusing anyway,
> like archaisms and slang.

Any specific examples that we can discuss?


> Having implemented much of what I could come up with on my own, I was
> wondering if anyone else had any ideas: something you've always
> thought that IF parsers should be able to understand or be smarter
> about, or some issue that often shows up and deserves a general
> solution, or just about any wild idea for that matter. All comments
> are welcome.

[...]

Here's an idea: we all know that natural language is ambiguous,
sometimes badly so (e.g., "time flies like an arrow; fruit flies like a
banana"). Most computer language parsers have unambiguous (or mostly
unambiguous) languages, and so most of the theory of parsing is geared
toward unambiguous grammars. But in IF, we *want* to deal with natural
languages, and therefore have to live with ambiguities. TADS 3 has made
some advancement in this area, in that if you refer to an ambiguous
object, it will first try to find the most logical match for that object
before giving up and asking the player to clarify what she means.

So what about extending this to deal with ambiguous sentence structures?
Given a sentence S, there is usually more than one way to parse it
(e.g., "time flies like an arrow" can have either 'time', 'flies', or
'like' as the verb, giving rise to at least 3 very different
interpretations of the sentence). Since we're not writing arcade games,
time isn't that much of an essence, so it should be feasible to
enumerate all possible parses of the sentence. Then, we can go through
each possibility, assigning to each a "sensibility" value. This value
reflects how likely that particular parse represents what the player
wants to do (e.g., a higher value is given if the resulting nouns and
verbs match the game's vocabulary, and a bonus score is given if the
nouns are in the PC's scope, etc.). At the end, if one possibility
clearly stands out from the rest, we assume that's what the player
intends, and go ahead with it.

To make this idea more concrete, let's take the pathological example
"time flies like an arrow". (This one isn't particularly exemplary of IF
commands, but it will suffice to describe this particular idea.) Here
are some ways in which in can be parsed:

1. time-VERB flies-NOUN (like an arrow)-ADVERB
2. time-NOUN flies-VERB (like an arrow)-ADVERB
3. (time flies)-NOUN like-VERB (an arrow)-NOUN

From a parser's standpoint, all of these are equally sensible. So how
does it decide which one is meant? (Or which one is more likely to be
meant?) By adopting TADS 3's approach: try to match up the verbs and
nouns with objects and actions in the game world. For example, if the
game happens to need an action of timing, then (1) gets a higher score.
If the game had a species of fly called 'time flies', then (3) would
also get a score boost. OTOH, if there are no such things as flies in
the game, then (1) and (3) would have a very low score, making (2) the
most likely possibility.

Here's a possible scenario: the game has the verbs 'fly' and 'time', and
you can refer to the current 'time', but has no such thing as 'flies'.
The parser would hypothetically go through the following decision
process:

(1) 'time' is a verb: +1
'flies' is a noun: -1 (there are no flies in this game)
Score: 0

(2) 'time' is a noun: +1 (we can refer to the time)
'flies' is a verb: +1 ('fly' is a verb in this game)
Score: 2

(3) 'time flies' is a noun: -1 (no such thing as flies in this game)
'like' is a verb: -1 (this game doesn't use the verb 'like')
Score: -2

The most likely meaning intended by the player is therefore (2).

Another scenario: the game has the verbs 'fly' and 'time', and there are
creatures known as 'time flies'. The decision process now is different:

(1) 'time' is a verb: +1
'flies' is a noun: 0 (it could refer to 'time flies', but it may not)
Score: 1

(2) 'time' is a noun: -1 (we don't need to refer to the current time)
'flies' is a verb: +1
Score: 0

(3) 'time flies' is a noun: +1 (this game has 'time flies')
'like' is a verb: -1 (this game doesn't use the verb 'like')
Score: 0

Result: (1) is the most likely meaning intended ('flies' could be
understood to refer to said 'time flies').

The key here is that the possibility chosen is *context-dependent*,
which is how we humans disambiguate these sentences in the first place.
The context, of course, is the contents of the game world. This helps
against comical (or more often, disastrous) misunderstandings of the
parser incongruous with the game world. E.g. "fly, fly away" could mean
the player wants to first fly, and then fly away, or it could be a
request to an NPC named 'fly' to fly away. The response "you see no fly
here" would be disastrous in a game where the player can fly, but would
make sense in a game in which the player can't fly but there's an NPC
called 'fly'. Similarly, "You can't fly" would be disastrous in a game
where the PC is trying to instruct the NPC 'fly' to fly away.


QF

--
Latin's a dead language, as dead as can be; it killed off all the
Romans, and now it's killing me! -- Schoolboy

Krister Fundin

unread,
Oct 13, 2006, 5:10:56 PM10/13/06
to

<quic...@quickfur.ath.cx> skrev i meddelandet
news:20061013202711.GB8094@crystal...

> On Fri, Oct 13, 2006 at 07:26:39PM +0000, Krister Fundin wrote:
>> I've been working for a while on an extension to improve the English
>> parser in one of the popular IF systems, adding some things that I've
>> been missing in existing parsers, or which might be appreciated by
>> newbies, or which are completely useless but rather amusing anyway,
>> like archaisms and slang.
>
> Any specific examples that we can discuss?

Well, here are some of the things from the extension:

- A generic USE verb (should be standard IMHO).

- Better and more uniform handling of interjections:

- YES
- BOB, YES
- SAY YES
- SAY YES TO BOB
- TELL BOB YES
- YES, BOB (to do)

- THIS/THAT/THESE/THOSE/THEM as both pronouns and articles.

- Understanding EVERY BOOK in addition to ALL THE BOOKS.

- Understanding PLEASE DO X (just like in Intercal).

- Understanding NOTHING, NEITHER ONE, etc. as an answer to
disambiguation questions.

- Directions: GO TO THE NORTH, GO EASTWARDS, and
GO SOUTH-EAST with a hyphen.

- Understanding the ampersand where AND is understood.

Plus lots of synonyms and new phrasings for various standard commands,
and some things that I can't remember now. Mostly simple stuff.

>> Having implemented much of what I could come up with on my own, I was
>> wondering if anyone else had any ideas: something you've always
>> thought that IF parsers should be able to understand or be smarter
>> about, or some issue that often shows up and deserves a general
>> solution, or just about any wild idea for that matter. All comments
>> are welcome.
> [...]
>
> Here's an idea: we all know that natural language is ambiguous,
> sometimes badly so (e.g., "time flies like an arrow; fruit flies like a
> banana"). Most computer language parsers have unambiguous (or mostly
> unambiguous) languages, and so most of the theory of parsing is geared
> toward unambiguous grammars. But in IF, we *want* to deal with natural
> languages, and therefore have to live with ambiguities. TADS 3 has made
> some advancement in this area, in that if you refer to an ambiguous
> object, it will first try to find the most logical match for that object
> before giving up and asking the player to clarify what she means.
>
> So what about extending this to deal with ambiguous sentence structures?

That's absolutely necessary, of course. Speaking of TADS 3, its grammar
often produces several alternative parse trees for a given command, and
the library parser has a whole range of rules for choosing between them.
For instance, THROW BOB BALL has two possible meanings, but one
of them can be ruled out as long as there is no object called "bob ball" in
the story. It would be interesting if the verification scheme could be used
to disambiguate actions as well as objects, but that's way beyond the
scope of my extension, which is more about extending IFese to a larger
part of the natural language.

-- Krister Fundin

Krister Fundin

unread,
Oct 13, 2006, 5:25:15 PM10/13/06
to

"Neil Cerutti" <hor...@yahoo.com> skrev i meddelandet
news:slrneivrap...@FIAD06.norwich.edu...

> Most IF parsers cannot cope if you use any words that it doesn't
> already know. This makes it impossible to generate actions with
> unknown objects, and usually the parser resorts to saying:
>
> If it is truthful: I don't know the word "humbug".
> If it is Inform: You can't see any such thing.
>
> It might be nice to permit the generation of actions with one or
> more unknown objects and let the author try to sort things out
> based on the text. Much better error messages could be one
> result.

I'm not sure if I follow. Do you mean that the player types, say, TAKE
THE TEMPERATURE, and as a last resort, this gets parsed as the
verb TAKE + some arbitrary text, and the ##Take action gets a chance
to try and figure out what it means?

> Another nice result would be that writing grammar to
> handle arbitrary conversation would become possible without doing
> all of the work yourself, and without the need to create special
> grammar tokens to gobble up arbitrary text.

Dunno. Seems that writing special grammar tokens would be easier
than looking at some text word by word. That said, I'm reminded of the
fact that TADS doesn't treat an unparsable order, E.G:

BOB, THIS IS ALL HUMBUG!

as saying some arbitrary text to Bob, which I do recall that Inform does.

-- Krister Fundin

Neil Cerutti

unread,
Oct 13, 2006, 6:53:01 PM10/13/06
to
On 2006-10-13, Krister Fundin <fun...@yahoo.com> wrote:
>
> "Neil Cerutti" <hor...@yahoo.com> skrev i meddelandet
> news:slrneivrap...@FIAD06.norwich.edu...
>> Most IF parsers cannot cope if you use any words that it doesn't
>> already know. This makes it impossible to generate actions with
>> unknown objects, and usually the parser resorts to saying:
>>
>> If it is truthful: I don't know the word "humbug".
>> If it is Inform: You can't see any such thing.
>>
>> It might be nice to permit the generation of actions with one or
>> more unknown objects and let the author try to sort things out
>> based on the text. Much better error messages could be one
>> result.
>
> I'm not sure if I follow. Do you mean that the player types,
> say, TAKE THE TEMPERATURE, and as a last resort, this gets
> parsed as the verb TAKE + some arbitrary text, and the ##Take
> action gets a chance to try and figure out what it means?

Yes, that's essentially what I mean.

>> Another nice result would be that writing grammar to handle
>> arbitrary conversation would become possible without doing all
>> of the work yourself, and without the need to create special
>> grammar tokens to gobble up arbitrary text.
>
> Dunno. Seems that writing special grammar tokens would be
> easier than looking at some text word by word. That said, I'm
> reminded of the fact that TADS doesn't treat an unparsable
> order, E.G:
>
> BOB, THIS IS ALL HUMBUG!
>
> as saying some arbitrary text to Bob, which I do recall that
> Inform does.

That is true.

Inform does have a 'topic' gammar token for scooping up arbitrary
text. Most of what I'm thinking about actually fairly doable.

--
Neil Cerutti

constantl...@gmail.com

unread,
Oct 13, 2006, 6:57:38 PM10/13/06
to
Hello!

I would hesitate to agree with the introduction of a generic USE verb.
Should the player really be relieved of the burden to explain what
exactly he has in mind with the objects he mentions?

I suggest two possible exceptions. Here is the first one:

>dig
What do you want to dig with?

>use the shovel
...

The second one consists of allowing the USE verb if the player has
already figured out how to apply a certain object.

OH, and PLEASE DO NOT program your parsers in Intercal!

Greetings,
EternalGamer

aaroni...@gmail.com

unread,
Oct 13, 2006, 7:11:36 PM10/13/06
to
Neil Cerutti wrote:
> Most IF parsers cannot cope if you use any words that it doesn't
> already know. This makes it impossible to generate actions with
> unknown objects, and usually the parser resorts to saying:
>
> If it is truthful: I don't know the word "humbug".
> If it is Inform: You can't see any such thing.

It's fairly easy in I7 to write code that will generate this kind of
output:

You can see a meteor, a stone, and a long glass of sherbet here.

>EXAMINE ROCK
I'm sorry, I don't know what you're referring to. Perhaps you meant the
meteor, the stone, or the long glass of sherbet?

>EXAMINE BLACK
You can't see the stranger in Black just now.

...which behavior I find to be much less frustrating to the player than
the standard Inform defaults.

Jim Aikin

unread,
Oct 13, 2006, 9:08:37 PM10/13/06
to
> Most IF parsers cannot cope if you use any words that it doesn't
> already know. This makes it impossible to generate actions with
> unknown objects, and usually the parser resorts to saying:
>
> If it is truthful: I don't know the word "humbug".
> If it is Inform: You can't see any such thing.

Seems to me the Inform response, though clunky, is fairly clever. The parser
avoids either admitting or denying that it knows the word. Since either
admitting it or denying it might be a spoiler, this is a good option.

In answer to Krister's query, I'd suggest perhaps allowing the parser to
sort through alternate word orders and missing or extra words. It's
annoying, for instance, if the parser understands 'look out window' but not
'look out of window'. Both can be coded, of course, but it would be a
courtesy to the author to handle it automatically. Ditto for 'turn light on'
as an alternative version of 'turn on light'.

I recently ran into a fairly obscure bit of confusion that's pertinent: In
most IF, the distinction between containers (which use 'in') and supporters
(which use 'on') is unambiguous. But consider a simple bookcase object, for
which the nouns 'bookcase', 'shelf', and 'shelves' are implemented. If the
user prefers 'shelf', it's a supporter, but if the user types 'bookcase',
it's a container. 'put book on shelf' is normal English, as is 'put book in
bookcase'.

I solved this in I6 by creating a fake 'shelf' supporter that diverts
anything placed on it to the bookcase. But there may be other situations
where 'on' and 'in' are equally valid, and it seems perhaps inelegant to
have the parser do this (which is what it did before I implemented my
workaround):

>put book on shelf
That can't contain things.

Here's a bigger topic: There are situations in which 'crawl' and 'go' may as
well be synonymous, but there are also situations (such as a low tunnel or a
narrow ledge) in which the author might reasonably want to insist that the
player crawl. So if there were some way to alert the parser about
situationally splittable partial synonyms.... Well, it's worth thinking
about.

--Jim Aikin

Neil Cerutti

unread,
Oct 13, 2006, 10:09:50 PM10/13/06
to
On 2006-10-14, Jim Aikin <rai...@musicwords.net> wrote:
>> Most IF parsers cannot cope if you use any words that it doesn't
>> already know. This makes it impossible to generate actions with
>> unknown objects, and usually the parser resorts to saying:
>>
>> If it is truthful: I don't know the word "humbug".
>> If it is Inform: You can't see any such thing.
>
> Seems to me the Inform response, though clunky, is fairly
> clever. The parser avoids either admitting or denying that it
> knows the word. Since either admitting it or denying it might
> be a spoiler, this is a good option.

I don't believe that hiding the dictionary from the player is a
good way to make games difficult. And in addition I'm still not
convinced that letting the player query the dictionary is liable
to spoil anything.

There's the wrinkle to consider that a game can understand more
words than are just in the dictionary, but I've not heard that
used as a justification.

Anyhow, the other behavior is easy to obtain. I guess I just
wanted to kvetch (a kvetch is, apparently, a very small troll).

> In answer to Krister's query, I'd suggest perhaps allowing the
> parser to sort through alternate word orders and missing or
> extra words. It's annoying, for instance, if the parser
> understands 'look out window' but not 'look out of window'.
> Both can be coded, of course, but it would be a courtesy to the
> author to handle it automatically. Ditto for 'turn light on' as
> an alternative version of 'turn on light'.

This another approach that will have good and bad effects. Nitfol
has a word-correctin algorithm that sometimes causes bad things
to happen, and this approach could to.

But mostly it's change from the standard interface. Neither good
nor bad until we've tried it out.

> Here's a bigger topic: There are situations in which 'crawl'
> and 'go' may as well be synonymous, but there are also
> situations (such as a low tunnel or a narrow ledge) in which
> the author might reasonably want to insist that the player
> crawl. So if there were some way to alert the parser about
> situationally splittable partial synonyms.... Well, it's worth
> thinking about.

It's possible to modify the grammar on the fly using General
Parsing Routines, and even some of the less heavyweight grammar
tokens. But you wouldn't want to do it very often, as it doesn't
look very pretty in the IDE.

The Inform Port of Ditch Day Drifter contains a Knock-Knock joke
with which you can play along.

! (P) knock_knock_joke global

! I'm going to use this global, in conjunction with some general parsing
! routines, to prevent the library from recognizing the knock-knock joke
! grammar unless the joke is being told.
Global knock_knock_joke=0; ! 0 -- No knock-knock joke.
! 1 -- Listening for "who's there?"
! 2 -- Listening for "madame who?"


! (9.2.4)
[ ParseAnything
wd;

do
wd=NextWordStopped();
until (wd == -1);
return 0;
];

! (9.2.5)
[ ParseThere
wd;

if (knock_knock_joke ~= 1) return -1;
wd=NextWord();
if (wd == 'there' or 'there?') return 0;
else return -1;
];

! (9.2.6)
[ ParseWho
wd;

if (knock_knock_joke ~= 2) return -1;
wd=NextWord();
if (wd == 'who' or 'who?') return 0;
else return -1;
];


! (10.9.4)
[ KnockOnSub;
if (noun has door && noun has openable) {
if (noun hasnt open) "Nobody opens the door.";
! I will waste a pile of code on a useless knock-knock joke easter egg,
! which you get by knocking on open doors.
else {
knock_knock_joke=1; ! Initiate the joke.
"Knock, knock.";
}
}
if (noun == player) "Ow.";
if (noun has animate) "I don't think ", (the) noun, " would care for that.";
"", (The) noun, " ", (IsOrAre) noun, " unresponsive.";
];

! (10.9.5)
Verb 'who^s'
* -> NonVerb
* ParseThere -> WhosThere
* ParseAnything -> NonVerb;

! (10.9.6)
Verb 'who'
* -> NonVerb
* 'is' -> NonVerb
* 'is' ParseThere ->WhosThere
* ParseAnything -> NonVerb;

! (10.9.7)
[ WhosThereSub;
knock_knock_joke=2; ! Recognize "madame who?"
"Madame.";
];

! (10.9.8)
Verb 'Madame'
* -> NonVerb
* ParseWho -> MadameWho
* ParseAnything -> NonVerb;

! (10.9.9)
! Simulate the libraries standard response to unknown verbs.
[ NonVerbSub;
"That's not a verb I recognize.";
];

! (10.9.10)
[ MadameWhoSub;
knock_knock_joke=0; ! Turn off the knock-knock joke grammar.
"Madame knock-knock joke isn't very funny.";
];

I'm glad I got that off my chest.

--
Neil Cerutti

Daryl McCullough

unread,
Oct 13, 2006, 11:50:46 PM10/13/06
to
Neil Cerutti says...

>Most IF parsers cannot cope if you use any words that it doesn't
>already know. This makes it impossible to generate actions with
>unknown objects, and usually the parser resorts to saying:
>
>If it is truthful: I don't know the word "humbug".
>If it is Inform: You can't see any such thing.

I think that it was intentional that Inform worked that way.
Suppose that the game responds one way if a "humbug" appears
in the game, but the player hasn't encountered it, but responds
another way if "humbug" is not used by the game at all. That
might give the player a hint as to what's to come, which some
authors may not intend.

I suppose that the game could treat *every* word that the
player has not yet encounted as if it were an unknown word,
but that would be a little weird, as well.

Maybe an ambiguous error message such as

>Whatever "humbug" might mean, there doesn't seem to be one here.

--
Daryl McCullough
Ithaca, NY

Adam Thornton

unread,
Oct 14, 2006, 12:38:20 AM10/14/06
to
In article <1160780258.6...@b28g2000cwb.googlegroups.com>,

<constantl...@gmail.com> wrote:
>OH, and PLEASE DO NOT program your parsers in Intercal!

ITYM, "PLEASE REFRAIN FROM progamming your parsers in INTERCAL!"

Adam

Krister Fundin

unread,
Oct 14, 2006, 6:15:04 AM10/14/06
to

<constantl...@gmail.com> skrev i meddelandet
news:1160780258.6...@b28g2000cwb.googlegroups.com...

> Hello!
>
> I would hesitate to agree with the introduction of a generic USE verb.
> Should the player really be relieved of the burden to explain what
> exactly he has in mind with the objects he mentions?

Yes, at least in the cases where the interpretation is obvious. There's no
reason to burden the player just for the hell of it. If the player types USE
DOOR or USE BUTTON or USE CHAIR, then I think the parser would
merely seem rude if it said something like "you'll have to be more
specific".
If a USE verb was standard, then I would probably type in commands like
the above all the time. It's only three letters; takes less time to type
than
GO THROUGH, PUSH or SIT ON.

> I suggest two possible exceptions. Here is the first one:
>
>>dig
> What do you want to dig with?
>
>>use the shovel
> ...

That's a case I hadn't thought of, but I think it should be possible to add.
The parser already understands if you write WITH THE SHOVEL when
answering the question, so it would just be a matter of adding the USE
phrase as another alternative. The only problem would be if the player
suddenly changed her mind and wrote something like:

>DIG


What do you want to dig with?

[oops, forgot the shovel back in the shed...]

>USE THE DOOR
You can't dig anything with the door!

> The second one consists of allowing the USE verb if the player has
> already figured out how to apply a certain object.

That would be desirable as well, but it's something the individual game
will have to take care of.

-- Krister Fundin

Krister Fundin

unread,
Oct 14, 2006, 6:30:06 AM10/14/06
to

<aaroni...@gmail.com> skrev i meddelandet
news:1160781096....@k70g2000cwa.googlegroups.com...
> [...]

>
>>EXAMINE BLACK
> You can't see the stranger in Black just now.
>
> ...which behavior I find to be much less frustrating to the player than
> the standard Inform defaults.

Yes, I've been thinking about this one too. When it comes to people,
some of our default error messages are less than good:

>TALK TO BOB


You can't see any such thing.

or

>TALK TO BOB
You can't see any bob here.

I would rather like to see some messages like:

Bob isn't here.
Bob just left. (then we can type FOLLOW HIM)
You last saw Bob in the kitchen.

This will probably be included in my extension.

-- Krister Fundin

Poster

unread,
Oct 14, 2006, 7:43:04 AM10/14/06
to

That would rock. Without getting too much into AI, I think one of the
problems with parsers is that they are not aware of what the player has
already seen or experienced. That is to say, they're not stateful.

Ideally there'd be a way to distinguish between generic objects and
people. While that would probably assume too much processing power to
handle (the parser would only know "the maiden" is different than "the
shovel" with a lot of specific rules), if you restrict this to an
awareness of people that the player has already seen in the game, that
would be reasonable and help create a more immersive experience.

-- Poster

www.intaligo.com Building, INFORM, Seasons (upcoming!)

quic...@quickfur.ath.cx

unread,
Oct 14, 2006, 1:18:05 PM10/14/06
to
On Fri, Oct 13, 2006 at 09:10:56PM +0000, Krister Fundin wrote:
>
> <quic...@quickfur.ath.cx> skrev i meddelandet
> news:20061013202711.GB8094@crystal...
> > On Fri, Oct 13, 2006 at 07:26:39PM +0000, Krister Fundin wrote:
> >> I've been working for a while on an extension to improve the English
> >> parser in one of the popular IF systems, adding some things that I've
> >> been missing in existing parsers, or which might be appreciated by
> >> newbies, or which are completely useless but rather amusing anyway,
> >> like archaisms and slang.
> >
> > Any specific examples that we can discuss?
>
> Well, here are some of the things from the extension:
>
> - A generic USE verb (should be standard IMHO).

Good idea. So I should be able to say USE SHOVEL instead of DIG GROUND
WITH SHOVEL?


> - Better and more uniform handling of interjections:
>
> - YES
> - BOB, YES
> - SAY YES

I think TADS 3 handles these already...?


> - SAY YES TO BOB
> - TELL BOB YES
> - YES, BOB (to do)

These are nice to have. Probably should be made standard. :-)


> - THIS/THAT/THESE/THOSE/THEM as both pronouns and articles.

Um... articles? Did you mean 'demonstratives'?


> - Understanding EVERY BOOK in addition to ALL THE BOOKS.

This should be standard, too.


> - Understanding PLEASE DO X (just like in Intercal).

"PLEASE <VERB> ..." would be a nice alternative too.


> - Understanding NOTHING, NEITHER ONE, etc. as an answer to
> disambiguation questions.

Nice. Although, of limited utility, unless there's a particular scenario
you have in mind that I didn't think of?


> - Directions: GO TO THE NORTH, GO EASTWARDS, and GO SOUTH-EAST with a
> hyphen.

These should be standard too, IMHO. They're of limited utility once
you're used to the standard shorthands (NE, SE, etc.), though.


> - Understanding the ampersand where AND is understood.

Not sure about this, but harmless, I guess.


> Plus lots of synonyms and new phrasings for various standard commands,
> and some things that I can't remember now. Mostly simple stuff.

OK. What about GIVE HIM THE BOOK as a synonym for GIVE THE BOOK TO HIM?
Some games only understand the latter, although TADS 3 understands both.
(I think this should be supported by default.)

This would, of course, need to be disambiguated from GIVE HIM TO THE
LION (the preposition changes the meaning of "HIM" from indirect object
to direct object).


[...]
> > Here's an idea: we all know that natural language is ambiguous,
> > sometimes badly so (e.g., "time flies like an arrow; fruit flies
> > like a banana"). Most computer language parsers have unambiguous (or
> > mostly unambiguous) languages, and so most of the theory of parsing
> > is geared toward unambiguous grammars. But in IF, we *want* to deal
> > with natural languages, and therefore have to live with ambiguities.
> > TADS 3 has made some advancement in this area, in that if you refer
> > to an ambiguous object, it will first try to find the most logical
> > match for that object before giving up and asking the player to
> > clarify what she means.
> >
> > So what about extending this to deal with ambiguous sentence
> > structures?
>
> That's absolutely necessary, of course. Speaking of TADS 3, its
> grammar often produces several alternative parse trees for a given
> command, and the library parser has a whole range of rules for
> choosing between them. For instance, THROW BOB BALL has two possible
> meanings, but one of them can be ruled out as long as there is no
> object called "bob ball" in the story. It would be interesting if the
> verification scheme could be used to disambiguate actions as well as
> objects, but that's way beyond the scope of my extension, which is
> more about extending IFese to a larger part of the natural language.

[...]

Oh, I didn't know TADS 3 already handles that. Yet another reason to be
glad for picking TADS 3 as my first IF language. :-)

On that note, I do want to see more automation in reconciling synonyms
for actions, whether or not you feel like implementing it. :-) For
example, RAISE FLAG should map to TURN CRANK ON FLAGPOLE if there's a
flagpole with a crank in the current room, but should map to HOLD UP
FLAG if I'm surrendering on a battlefield while holding a white flag.
In other words, verbs may sometimes map to multiple actions, and which
one is meant is decided based on context.

Natural language is full of this kind of polysemy, and accounting for at
least the common cases will go a long way to improving parsing in IF.


QF

--
Food and laptops don't mix.

JDC

unread,
Oct 14, 2006, 1:46:56 PM10/14/06
to

Krister Fundin wrote:
> >TALK TO BOB
> You can't see any bob here.
>
> I would rather like to see some messages like:
>
> Bob isn't here.
> Bob just left. (then we can type FOLLOW HIM)
> You last saw Bob in the kitchen.

In Inform 7 you can do something like this using the "printing a parser
error" activity. The following is a pretty basic first approximation:

<code>
After deciding the scope of the player while printing a parser error:
place Bob in scope.

Rule for printing a parser error when parser error is can't see any
such thing:
if the player's command includes "[Bob]" and Bob is not in the
location, say "Bob is in [location of Bob]." instead;
otherwise say "You can't see any such thing."
</code>

-JDC

Krister Fundin

unread,
Oct 14, 2006, 3:06:37 PM10/14/06
to

<quic...@quickfur.ath.cx> skrev i meddelandet
news:20061014171912.GA8533@crystal...

> On Fri, Oct 13, 2006 at 09:10:56PM +0000, Krister Fundin wrote:
>> Well, here are some of the things from the extension:
>>
>> - A generic USE verb (should be standard IMHO).
>
> Good idea. So I should be able to say USE SHOVEL instead of DIG
> GROUND WITH SHOVEL?

Yes, and ditto for anything else that has a single obvious use.

>> - Better and more uniform handling of interjections:
>>
>> - YES
>> - BOB, YES
>> - SAY YES
>
> I think TADS 3 handles these already...?

It does, except that YES and SAY YES are synonymous, so a command
like TELL BOB TO SAY YES wouldn't have the desired effect. (It
would be trated the same way as BOB, YES.)

>> - THIS/THAT/THESE/THOSE/THEM as both pronouns and articles.
>
> Um... articles? Did you mean 'demonstratives'?

Yeah, I guess. A sample command could be: TAKE FIVE OF THEM
APPLES AND PUT THOSE ON THAT TABLE.

>> - Understanding PLEASE DO X (just like in Intercal).
>
> "PLEASE <VERB> ..." would be a nice alternative too.

That's what I meant. PLEASE TAKE THE BOOK, or TAKE THE
BOOK PLEASE.

>> - Understanding NOTHING, NEITHER ONE, etc. as an answer to
>> disambiguation questions.
>
> Nice. Although, of limited utility, unless there's a particular scenario
> you have in mind that I didn't think of?

It's a newbie thing. You don't want to answer the question, but don't
know that you can type another command instead. Typing NOTHING
or equivalent results in a short message explaining the situation.

>> - Directions: GO TO THE NORTH, GO EASTWARDS, and GO
>> SOUTH-EAST with a hyphen.
>
> These should be standard too, IMHO. They're of limited utility once
> you're used to the standard shorthands (NE, SE, etc.), though.

Sure. They're mostly for completion. I remember reading some getting-
started-with-IF texts a few years back, and more than one specifically
mentioned that hyphenated directions must not be used. I never
understood why they couldn't simply implement this and get on with it.
I suppose it's related to the 6 characters limit on dictionary words in
Z3 and earlier, but we should have gotten past that by now.

>> - Understanding the ampersand where AND is understood.
>
> Not sure about this, but harmless, I guess.

Again, it's mostly for completion.

> OK. What about GIVE HIM THE BOOK as a synonym for GIVE
> THE BOOK TO HIM? Some games only understand the latter,
> although TADS 3 understands both.
> (I think this should be supported by default.)

I agree. This happens to be a TADS 3 extension, though, so that's
already covered. ISTR that later version of Inform handle this too.

> On that note, I do want to see more automation in reconciling synonyms
> for actions, whether or not you feel like implementing it. :-) For
> example, RAISE FLAG should map to TURN CRANK ON
> FLAGPOLE if there's a flagpole with a crank in the current room, but
> should map to HOLD UP FLAG if I'm surrendering on a battlefield
> while holding a white flag. In other words, verbs may sometimes map to
> multiple actions, and which one is meant is decided based on context.

Yes, and PUT THE HAT ON doesn't map to the same action as PUT
THE KETTLE ON either. I think it would be nice if we could have a
finer distinction between actions (which always mean the same thing) and
commands (which don't necessarily). We'd have fewer actions but more
commands. Translations would be easier that way too. But this is also
beyond the scope of my extension.

-- Krister Fundin

Emily Short

unread,
Oct 14, 2006, 3:08:42 PM10/14/06
to

JDC wrote:
> In Inform 7 you can do something like this using the "printing a parser
> error" activity. The following is a pretty basic first approximation:
>
> <code>
> After deciding the scope of the player while printing a parser error:
> place Bob in scope.
>
> Rule for printing a parser error when parser error is can't see any
> such thing:
> if the player's command includes "[Bob]" and Bob is not in the
> location, say "Bob is in [location of Bob]." instead;
> otherwise say "You can't see any such thing."
> </code>

And with slightly more complexity:

<code>
A thing can be seen or unseen.

Definition: a thing is distant if the location of it is not the
location.

After printing the name of something (called target): now the target is
seen.

After deciding the scope of the player while printing a parser error:

repeat with item running through seen things
begin;
place item in scope;
end repeat.

Rule for printing a parser error when parser error is can't see any
such thing:

if the player's command includes "[a seen distant thing]", say
"[The noun] is in [the location of noun]." instead;


otherwise
say "You can't see any such thing."

Rule for printing a parser error when parser error is can only do that
to something animate:
if the player's command includes "[a seen distant person]", say
"[The noun] is in [the location of noun]." instead;
otherwise
say "You can only do that to something animate."
</code>

There may still be some problems with this. But it does handle this
sort of thing:

>kiss bob


You can't see any such thing.

>s

Library
You can see Bob here.

>n

Kitchen

>kiss bob
Bob is in the Library.

Emily Short

unread,
Oct 14, 2006, 3:15:32 PM10/14/06
to

Krister Fundin wrote:
> Having implemented much of what I could come up with on my own, I was
> wondering if anyone else had any ideas: something you've always thought
> that IF parsers should be able to understand or be smarter about, or
> some issue that often shows up and deserves a general solution, or just
> about any wild idea for that matter. All comments are welcome.

Two things I found in novice logs, and have tried to account for when
writing my own games for new players:

1) players using unconventional kinds of movement command, especially
GO TO [named room] and GO BACK (or variations on it) to mean "return to
the room I was just in".

2) players using adverbial phrases, especially referring to body parts
-- HIT MAN WITH FIST, etc. These are a bit harder to catch, but I have
tried putting in matches that find and delete these from a command
before parsing, sometimes with a short explanation that that "with
[body part]" isn't necessary or understood by the game.

quic...@quickfur.ath.cx

unread,
Oct 14, 2006, 7:15:39 PM10/14/06
to
On Sat, Oct 14, 2006 at 07:06:37PM +0000, Krister Fundin wrote:
>
> <quic...@quickfur.ath.cx> skrev i meddelandet
> news:20061014171912.GA8533@crystal...
> > On Fri, Oct 13, 2006 at 09:10:56PM +0000, Krister Fundin wrote:
> >> Well, here are some of the things from the extension:
> >>
> >> - A generic USE verb (should be standard IMHO).
> >
> > Good idea. So I should be able to say USE SHOVEL instead of DIG
> > GROUND WITH SHOVEL?
>
> Yes, and ditto for anything else that has a single obvious use.

Cool.


> >> - Better and more uniform handling of interjections:
> >>
> >> - YES
> >> - BOB, YES
> >> - SAY YES
> >
> > I think TADS 3 handles these already...?
>
> It does, except that YES and SAY YES are synonymous, so a command
> like TELL BOB TO SAY YES wouldn't have the desired effect. (It
> would be trated the same way as BOB, YES.)

Hmm. That would be odd... although I can't confirm if TADS 3 does this
from a cursory test.


> >> - THIS/THAT/THESE/THOSE/THEM as both pronouns and articles.
> >
> > Um... articles? Did you mean 'demonstratives'?
>
> Yeah, I guess. A sample command could be: TAKE FIVE OF THEM APPLES AND
> PUT THOSE ON THAT TABLE.

Hmm. I'd use "THE" instead of "THEM", although I guess it's harmless for
the parser to be lenient here.


[...]


> >> - Understanding NOTHING, NEITHER ONE, etc. as an answer to
> >> disambiguation questions.
> >
> > Nice. Although, of limited utility, unless there's a particular scenario
> > you have in mind that I didn't think of?
>
> It's a newbie thing. You don't want to answer the question, but don't
> know that you can type another command instead. Typing NOTHING
> or equivalent results in a short message explaining the situation.

OK.


[...]


> > On that note, I do want to see more automation in reconciling
> > synonyms for actions, whether or not you feel like implementing it.
> > :-) For example, RAISE FLAG should map to TURN CRANK ON FLAGPOLE if
> > there's a flagpole with a crank in the current room, but should map
> > to HOLD UP FLAG if I'm surrendering on a battlefield while holding a
> > white flag. In other words, verbs may sometimes map to multiple
> > actions, and which one is meant is decided based on context.
>
> Yes, and PUT THE HAT ON doesn't map to the same action as PUT THE
> KETTLE ON either. I think it would be nice if we could have a finer
> distinction between actions (which always mean the same thing) and
> commands (which don't necessarily). We'd have fewer actions but more
> commands. Translations would be easier that way too. But this is also
> beyond the scope of my extension.

[...]

Bingo. I think you've hit upon the key here: verbs and actions are
different things, albeit related, and we'd like to automatically handle
ambiguous mappings from verbs to actions where possible. I think it
shouldn't be *too* hard to extend the current TADS 3 system to handle
this: it already goes through all ambiguous nouns, evaluating the
"logicalness" of each combination of objects, and picking the one that
seems most likely (or prompting the player to clarify what she means).
Now all we need is to do that for different actions as well. So for each
verb, there may be one or more associated actions, and we simply
evaluate the "logicalness" of each possible action as before (which
yields the most "logical" combination of objects for each of the
actions), and pick the action which has the highest "logical" value.


QF

--
Life is too short to run proprietary software. -- Bdale Garbee

she's long gone

unread,
Oct 15, 2006, 12:04:13 AM10/15/06
to

Jim Aikin wrote:
> Seems to me the Inform response, though clunky, is fairly clever. The parser
> avoids either admitting or denying that it knows the word. Since either
> admitting it or denying it might be a spoiler, this is a good option.

This is solvable if the game has a way to know which things the player
is aware of, and which he isn't. That's not very difficult, nor is it
much more work to produce something like

"You last saw the apple pie on the kitchen table."

Daryl McCullough

unread,
Oct 15, 2006, 11:37:00 AM10/15/06
to
Neil Cerutti says...

>I don't believe that hiding the dictionary from the player is a
>good way to make games difficult. And in addition I'm still not
>convinced that letting the player query the dictionary is liable
>to spoil anything.

I certainly don't want to hide information from the player in
order to make things more *difficult*, but I think that hiding
information from the player can sometimes heighten the emotional
impact of a scene. If you know that the game is going to involve
ghosts, or aliens, or evil robots, or something, then it takes
a little bit of the edge off a mystery. And if the word "ghost"
is in the dictionary, then you can bet the game is about ghosts.

Benjamin Caplan

unread,
Oct 15, 2006, 3:16:30 PM10/15/06
to

I'm cross-posting this to rgif because I think that we really need a
players'-side view on this question. It's the kind of thing that beta
testing was invented for.

So, players of interactive fiction, what kinds of annoyances and
frustrations do you most often experience with the IF parser?

(Yes, I know there's a lot of crossover between the r*ifs.)

Richard Bos

unread,
Oct 15, 2006, 5:49:52 PM10/15/06
to
quic...@quickfur.ath.cx wrote:

> On Fri, Oct 13, 2006 at 09:10:56PM +0000, Krister Fundin wrote:
> >
> > <quic...@quickfur.ath.cx> skrev i meddelandet
> > news:20061013202711.GB8094@crystal...
> > > On Fri, Oct 13, 2006 at 07:26:39PM +0000, Krister Fundin wrote:
> > >> I've been working for a while on an extension to improve the English
> > >> parser in one of the popular IF systems, adding some things that I've
> > >> been missing in existing parsers, or which might be appreciated by
> > >> newbies, or which are completely useless but rather amusing anyway,
> > >> like archaisms and slang.
> > >
> > > Any specific examples that we can discuss?
> >
> > Well, here are some of the things from the extension:
> >
> > - A generic USE verb (should be standard IMHO).
>
> Good idea. So I should be able to say USE SHOVEL instead of DIG GROUND
> WITH SHOVEL?

Yes. You'll also be able to USE SHOVEL instead of HIT MUGGER WITH
SHOVEL. If you're being mugged in a garden, USE SHOVEL will use the
random number generator to decide which of the two possible actions you
meant.

> > - THIS/THAT/THESE/THOSE/THEM as both pronouns and articles.
>
> Um... articles? Did you mean 'demonstratives'?

Anyway, they are all already supported as pronouns in Inform 6; as
demonstratives, their value is limited. When I say GET THOSE BOOKS,
_which_ "those books" do I mean? IRL, it's easy to point, but that's
harder on a computer screen.

> > - Understanding EVERY BOOK in addition to ALL THE BOOKS.
>
> This should be standard, too.

Already the case in Inform 6.

> > - Understanding PLEASE DO X (just like in Intercal).
>
> "PLEASE <VERB> ..." would be a nice alternative too.

PLEASE REFRAIN FROM SUPPORTING PLEASE.

> > Plus lots of synonyms and new phrasings for various standard commands,
> > and some things that I can't remember now. Mostly simple stuff.
>
> OK. What about GIVE HIM THE BOOK as a synonym for GIVE THE BOOK TO HIM?
> Some games only understand the latter, although TADS 3 understands both.

Inform, too.


Richard

Richard Bos

unread,
Oct 15, 2006, 5:49:53 PM10/15/06
to
"Krister Fundin" <fun...@yahoo.com> wrote:

> <quic...@quickfur.ath.cx> skrev i meddelandet

> > On Fri, Oct 13, 2006 at 09:10:56PM +0000, Krister Fundin wrote:
> >> - THIS/THAT/THESE/THOSE/THEM as both pronouns and articles.
> >
> > Um... articles? Did you mean 'demonstratives'?
>
> Yeah, I guess. A sample command could be: TAKE FIVE OF THEM
> APPLES AND PUT THOSE ON THAT TABLE.

"Them apples"? That's bad English. Anyway, which "that" table? Just the
single table that's present? Then "the table" works just as well.

Richard

Krister Fundin

unread,
Oct 16, 2006, 6:41:31 AM10/16/06
to

"Richard Bos" <ral...@xs4all.nl> skrev i meddelandet
news:45324b04...@news.xs4all.nl...

> "Krister Fundin" <fun...@yahoo.com> wrote:
>
>> TAKE FIVE OF THEM APPLES AND PUT THOSE ON THAT
>> TABLE.
>
> "Them apples"? That's bad English.

Regional maybe -- I wouldn't know. My dictionary mentions this
phrasing under possible uses for "them".

> Anyway, which "that" table? Just the single table that's present? Then
> "the table" works just as well.

Certainly. But someone could still conceivably type "that table", and
there's no particular reason not to allow it.

-- Krister Fundin

JDC

unread,
Oct 16, 2006, 9:04:13 AM10/16/06
to

Richard Bos wrote:
> > Yeah, I guess. A sample command could be: TAKE FIVE OF THEM
> > APPLES AND PUT THOSE ON THAT TABLE.
>
> "Them apples"? That's bad English. Anyway, which "that" table? Just the
> single table that's present? Then "the table" works just as well.

Yeah, it should really be: TAKE FIVE OF THEM APPLES AND PUT THOSE ON
THAT THERE TABLE.

-JDC

Neil Cerutti

unread,
Oct 16, 2006, 10:18:53 AM10/16/06
to

In English it seems like a simple enhancement. I say why not
accept regional dialects when it's so cheap?

--
Neil Cerutti

Eric Eve

unread,
Oct 16, 2006, 11:14:33 AM10/16/06
to
"Jim Aikin" <rai...@musicwords.net> wrote in message
news:pMWXg.6719

> Here's a bigger topic: There are situations in which 'crawl' and
> 'go' may as well be synonymous, but there are also situations
> (such as a low tunnel or a narrow ledge) in which the author might
> reasonably want to insist that the player crawl. So if there were
> some way to alert the parser about situationally splittable
> partial synonyms.... Well, it's worth thinking about.

At least in TADS 3, I6 and I7 this is already possible, at least for
game authors (who would have to be the people to deal with this
level of detail, rather than library or extension writers). All
three systems allow you to check what verb the player actually
typed, so that if CRAWL and GO were synonymous in 90% of cases
(making it convenient to have them trigger the same action) in the
other 10% of cases you could check the player's input to split the
responses to the two verbs. This doesn't seem to require any new
standard parser features, unless there was something else you had in
mind.

-- Eric


Eric Eve

unread,
Oct 16, 2006, 11:28:17 AM10/16/06
to

<quic...@quickfur.ath.cx> wrote in message
news:20061014171912.GA8533@crystal...

> On that note, I do want to see more automation in reconciling
> synonyms
> for actions, whether or not you feel like implementing it. :-) For
> example, RAISE FLAG should map to TURN CRANK ON FLAGPOLE if
> there's a
> flagpole with a crank in the current room, but should map to HOLD
> UP
> FLAG if I'm surrendering on a battlefield while holding a white
> flag.
> In other words, verbs may sometimes map to multiple actions, and
> which
> one is meant is decided based on context.

I'd have thought this kind of thing was up to individual game
authors to sort out; libraries and extensions can hardly be expected
to have a sufficiently detailed knowledge of particular game worlds
(many games won't have flags at all; those that do might use them in
all sorts of different ways), while conversely any decent existing
IF system will allow an author to vary what a command does according
to context (it would be difficult to write decent IF without this
ability). So I'm not sure whether this amounts to much more in
practice than a plea for authors to be a bit smarter about
customising the way some commands interact with some game objects.

To expand just a little, I see it as the job of the general parser
(as supplied by the library or an extension) to parse the player's
input (RAISE FLAG, HOIST THE FLAG, RAISE THE GREEN FLAG or whatever)
so that it resolves to, say, the Raise action and the greenFlag
object (after taking into account scope and any other such
considerations the parser uses to resolve ambiguity). It's then up
to the game author to program what performing the Raise action on
the greenFlag object actually does (if it's not simply some
default), and that task surely includes checking for context, e.g.:

instead of raising the green flag when the player can touch the
flagpole:
try turning the crank.

Or

greenFlag: Thing 'green flag*flag' 'green flag'
...
dobjFor(Raise) maybeRemapTo(actor.canTouch(flagPole), Turn, crank)

;

-- Eric


Nathan

unread,
Oct 16, 2006, 11:32:50 AM10/16/06
to
Benjamin Caplan wrote:
> So, players of interactive fiction, what kinds of annoyances and
> frustrations do you most often experience with the IF parser?

I don't know whether this is a function of the parser *per se*, but
I've always been bothered by games arbitrarily changing the
antecedent of IT. This was a particular problem with Infocom
games, but I've experienced it with recent games too.

Somewhat related, but maybe I'm alone here: I dislike
maintaining a strict distinction between IT and THEM, such
that I can't refer to the last object as IT if it's plural.

Eric Eve

unread,
Oct 16, 2006, 11:52:56 AM10/16/06
to

"Nathan" <nts...@netscape.net> wrote in message
news:1161012770.9...@k70g2000cwa.googlegroups.com...

> I don't know whether this is a function of the parser *per se*,
> but
> I've always been bothered by games arbitrarily changing the
> antecedent of IT. This was a particular problem with Infocom
> games, but I've experienced it with recent games too.

If it truly is arbitrary then it's likely to be annoying. Ideally a
parser should try to deduce what a player most likely means by IT in
terms of the last noun the player explicitly referred to. But there
are two problems with this seemingly simple rule:

(1) The player may just have referred to two objects, e.g. PUT
THE BALL IN THE BOWL. If the player issues the command TAKE IT on
the next turn, does IT mean the ball or the bowl? (I'd personally go
for the ball in this situation, but it's conceivable that the player
meant the bowl, but the parser can't be expected to rad the player's
mind here).

(2) The game may have responded to the player's last command with
text that calls attention to a particular object not previously
mentioned, e.g.:

>LOOK UNDER CARPET
Under the carpet you find a gleaming diamond.

A player who types TAKE IT next probably means IT to refer to the
diamond rather than the carpet; is it arbitrary to change the
antecedent in such a case in anticipation of this piece of player
psychology? Or should one stick to the rule that IT must refer to
the noun the player last refer to:

>TAKE IT
The carpet is too heavy for you to carry around with you.

> Somewhat related, but maybe I'm alone here: I dislike
> maintaining a strict distinction between IT and THEM, such
> that I can't refer to the last object as IT if it's plural.

This is a bit double-edged. Where an object is ambiguously plural
(e.g. a pair of shoes), I'd agree with you: IT could naturally refer
to the pair and THEM to the shoes, so a player could reasonably use
either pronoun. In other contexts it's more helpful to the player to
maintain a strict distinction:

>PUT GRAPES IN BOWL.

IT now naturally refers to the bowl, and THEM to the grapes.

Or even

>X BOWL
It's full of grapes.

>X GRAPES
They're green and round.

>TAKE IT
[The bowl or the grapes? I think the most reasonable expectation is
that this should be the bowl, and that thad the player meant the
grapes s/he should have typed TAKE THEM. If, however, we had:

>X BOWL
In the bowl is a bunch of grapes.

Then immediately after we've referred to the grapes (X BUNCH or X
GRAPES) then IT perhaps most naturally refers to the bunch.

So it's hard to generalize!

-- Eric


quic...@quickfur.ath.cx

unread,
Oct 16, 2006, 12:07:06 PM10/16/06
to
On Mon, Oct 16, 2006 at 10:41:31AM +0000, Krister Fundin wrote:
>
> "Richard Bos" <ral...@xs4all.nl> skrev i meddelandet
> news:45324b04...@news.xs4all.nl...
> > "Krister Fundin" <fun...@yahoo.com> wrote:
> >
> >> TAKE FIVE OF THEM APPLES AND PUT THOSE ON THAT
> >> TABLE.
> >
> > "Them apples"? That's bad English.
>
> Regional maybe -- I wouldn't know. My dictionary mentions this
> phrasing under possible uses for "them".
[...]

It's slang. Slang is not necessarily "incorrect", just that you wouldn't
use it outside of an informal, with-my-good-friends context.


QF

--
One who has not yet appreciated the beauty of language is not worthy to
bemoan its flaws.

Steve

unread,
Oct 16, 2006, 12:26:52 PM10/16/06
to

WTF is wrong with Intercal? By all accounts it is a perfectly
reasonable language for general computing purposes. Sure, it may be a
little wierd, but that's just part of its charm.


Regards,

Steve

quic...@quickfur.ath.cx

unread,
Oct 16, 2006, 12:34:37 PM10/16/06
to
On Mon, Oct 16, 2006 at 04:28:17PM +0100, Eric Eve wrote:
>
> <quic...@quickfur.ath.cx> wrote in message
> news:20061014171912.GA8533@crystal...
>
> > On that note, I do want to see more automation in reconciling
> > synonyms for actions, whether or not you feel like implementing it.
> > :-) For example, RAISE FLAG should map to TURN CRANK ON FLAGPOLE if
> > there's a flagpole with a crank in the current room, but should map
> > to HOLD UP FLAG if I'm surrendering on a battlefield while holding a
> > white flag. In other words, verbs may sometimes map to multiple
> > actions, and which one is meant is decided based on context.
>
> I'd have thought this kind of thing was up to individual game authors
> to sort out; libraries and extensions can hardly be expected to have a
> sufficiently detailed knowledge of particular game worlds

That's not my point at all; the point is that the context, which is game
world dependent, is specified by the author, and based on this
information the library maps verbs differently.


> (many games won't have flags at all; those that do might use them in
> all sorts of different ways), while conversely any decent existing IF
> system will allow an author to vary what a command does according to
> context (it would be difficult to write decent IF without this
> ability). So I'm not sure whether this amounts to much more in
> practice than a plea for authors to be a bit smarter about customising
> the way some commands interact with some game objects.

My point was that this customisation should be more automated than it
currently is.


> To expand just a little, I see it as the job of the general parser (as
> supplied by the library or an extension) to parse the player's input
> (RAISE FLAG, HOIST THE FLAG, RAISE THE GREEN FLAG or whatever) so that
> it resolves to, say, the Raise action and the greenFlag object (after
> taking into account scope and any other such considerations the parser
> uses to resolve ambiguity).

Yes, this is what I was driving at. How easy is it under the current
TADS 3 system to do this?

AFAIK, if I want a non-standard verb as a synonym (e.g. "hoist") I have
to actually go through the trouble of defining a Hoist verb, and
possibly a HoistAction if I anticipate the verb 'hoist' to mean
something else in another part of the game, and add remapTo()'s for
different objects for which the action is possible. I was hoping for a
cleaner separation between verb and action, such that the author could
simply list a set of verb rules and specify (somewhere) that they map to
a certain action. E.g., something to the effect of:

mapPhraseToAction [
'raise {greenFlag}',
'hoist {greenFlag}',
'turn {flagpoleCrank}',
... etc.
] -> [ RaiseAction, greenFlag ];

greenFlag : Thing {
...
dobjFor(RaiseAction) { /* raise the flag */ }
}

and then somewhere else, you may have something like:

mapPhraseToAction [
'hoist car [with crane]'
'lift car [with crane]'
'pick up car [with crane]'
...
] -> [ LiftWithAction, theCar, theCrane ];

The library then collects all of these phrase mappings, and figures out
that if the verb 'hoist' is used with an object, it should check whether
the object is greenFlag or theCar, and map it to [RaiseAction,
greenFlag] or [LiftWithAction, theCrane], respectively.


> It's then up to the game author to program what performing the Raise
> action on the greenFlag object actually does (if it's not simply some
> default), and that task surely includes checking for context, e.g.:
>
> instead of raising the green flag when the player can touch the
> flagpole:
> try turning the crank.
>
> Or
>
> greenFlag: Thing 'green flag*flag' 'green flag'
> ...
> dobjFor(Raise) maybeRemapTo(actor.canTouch(flagPole), Turn, crank)
>
> ;

[...]

What if you also want to use the verb 'turn' in, say, the phrase TURN
AROUND? Or maybe, if the game has a polymorphic PC, TURN INTO A FROG. I
know this can all be done if the author defines enough new verb rules
and remappings, but I think games would benefit a lot more if the
library could handle a lot of this tedious work more automatically.
(Many authors would simply give up if too much work is involved when all
they want is to specify an alternate phrasing of a particular action.)
The verb/action distinction would help a lot in simplifying the code
required to implement TURN THE CRANK, TURN AROUND, and TURN INTO A FROG
in the same game (with all the possible alternate phrasings and their
respective verbs).

Or maybe there's already a clean way of doing this and I'm just speaking
out of ignorance.


QF

--
This is not a sentence.

Andrew Plotkin

unread,
Oct 16, 2006, 12:53:35 PM10/16/06
to
In rec.games.int-fiction, Eric Eve <eric...@nospamhmc.ox.ac.uk> wrote:
>
> "Nathan" <nts...@netscape.net> wrote in message
> news:1161012770.9...@k70g2000cwa.googlegroups.com...
> > I don't know whether this is a function of the parser *per se*,
> > but
> > I've always been bothered by games arbitrarily changing the
> > antecedent of IT. This was a particular problem with Infocom
> > games, but I've experienced it with recent games too.
>
> If it truly is arbitrary then it's likely to be annoying. Ideally a
> parser should try to deduce what a player most likely means by IT in
> terms of the last noun the player explicitly referred to.

Inform 6 has long had a feature (and I'd rather put that in
nasty-quotes) where IT refers to the last noun that the *game*
explicitly referred to. So "inventory" and "look" change the referent.
(And if "look" mentions a person, the referent of "he" or "she"
changes. Etc.)

I believe Inform 7 has inherited that feature. It can be turned off,
but since authors don't know about it, they don't consider the
question.

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Bush's biggest lie is his claim that it's okay to disagree with him. As soon as
you *actually* disagree with him, he sadly explains that you're undermining
America, that you're giving comfort to the enemy. That you need to be silent.

Emily Short

unread,
Oct 16, 2006, 12:57:58 PM10/16/06
to

Andrew Plotkin wrote:
> Inform 6 has long had a feature (and I'd rather put that in
> nasty-quotes) where IT refers to the last noun that the *game*
> explicitly referred to. So "inventory" and "look" change the referent.
> (And if "look" mentions a person, the referent of "he" or "she"
> changes. Etc.)
>
> I believe Inform 7 has inherited that feature. It can be turned off,
> but since authors don't know about it, they don't consider the
> question.

I keep forgetting to add this to the feature-change-requests list, but
I am doing so now.

Adam Thornton

unread,
Oct 16, 2006, 12:45:52 PM10/16/06
to
In article <1161016012.3...@k70g2000cwa.googlegroups.com>,

You have missed both the point and the joke. Also, name *one* such
account. It's perfectly reasonable in the same sense that Brainf*ck is
perfectly reasonable.

Adam

Jim Aikin

unread,
Oct 16, 2006, 2:00:34 PM10/16/06
to

There may be even easier ways to do it. In I6, I'd try creating two separate
verbs, and then do something like this:

[ CrawlSub; <<Go noun>>; ];

As a first approximation, that would redirect the 'crawl' action everywhere
except where I want to intercept it somehow.

Truth be told, given the existing languages' ability to check what the
player actually typed, are any new parser features actually needed? Probably
not, if the author is willing to hack her way through whatever weird cases
may come up.

I think Krister was looking for feedback about what may come up often enough
to be worth implementing as a general case. I don't claim to have any
insights into what would be more useful to more people more of the time ...
I'm just tossing out ideas.

--JA


Autymn D. C.

unread,
Oct 16, 2006, 2:44:27 PM10/16/06
to
Benjamin Caplan wrote:
> So, players of interactive fiction, what kinds of annoyances and
> frustrations do you most often experience with the IF parser?

That I can't use 'search all' or 'get all' or 'x all' in nearly all
games/imps. :D

I would like to anwrite the dictionary to take original and consistent
ME, sheerly grammatic and literal-verbal input. 'go', for example,
means "try". So 'go west' is verbally wrong because it means "try
west". So I'd replace it with something like 'meet west' or 'see
west', where "west" is anything. IOW, I want my own verbs. Then
again, we don't need a verb for directions. This is like the old
debate about the one or two clicks needed to open icòns rather than
entry in a command line. If the parser were verbal, 'west' would
return 'Huh?' or "'west' is not a verb I recognise.". (But it's
sentimental.) IF's grammar is markedly American (as in the natives)
that conjugats by space, over European that conjugats by time.

"Imagine" a gameworld without turns and rooms and actions. (Never
mind--there are, but they're loosser.) Commands are more contextual
and treelike. 'undo' is not global but is aware of what [manual]
commands are neded to take back the last, as well as give back with
'ando'. How about further commands like 'rear' and 'get' to plan and
recall.

As for spots, in a "room"'s description one is compelled to write where
every other "room" or thing is off a compass direction, when we don't
think in terms of the compass but with walls, paths, and our own head
and what we ken therewith. If you can ken it, you can track it, and
you don't need to choose which global direction to follow to meet it.
So, uh, let's abolish roomnames, and program a bunch of objects with
letters and lotters (base-64, like youtube) as tags/flags that link to
each other in nearness. "But rooms are real!" Yeah, put whatever name
it feels like in the description, but it'll be dead in the map. 'call
here [enth] spot' to backtrack if you want, otherwise 'among', 'about',
'along', 'awith', 'ahead', 'ahind', 'astride', 'aside', 'atop', 'abot'.
(Well lookkee there, I'v ten fingers as well.)

So there can be duplicate items that differ onely in their tag. (Tags
become slots if they're on you.) For commands without demonstrativs,
the "it" or "who" or "deed" will be in bold in the output. The
gameworld is a great piece of furniture.

Time needs a meetly list as well, such as to make 'wait' and 'yes' more
sòfisticated. I could use the same ten, with i- or y- instead of a-,
where many of the offways are in imaginary or mental dimensions.
'wait' is 'istride', 'help' is 'iside'; 'ilong' and 'ihead' apply if
the player or writere pland (rearrd) a [hi]story that the player is
aware of (or iware of). (Now this feels like Puzz3D or 3D chess!)
'itop' and 'ibot' are for how byssy you'll go. 'among' and 'imong' are
by default after a 'meet'.

-Aut
>22,19

Gene Wirchenko

unread,
Oct 16, 2006, 2:44:17 PM10/16/06
to
constantl...@gmail.com wrote:

[snip]

>OH, and PLEASE DO NOT program your parsers in Intercal!

Why not? BRAINFUCK has already been done.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Eric Eve

unread,
Oct 16, 2006, 5:20:22 PM10/16/06
to
<quic...@quickfur.ath.cx> wrote in message
news:20061016163521.GB19168@crystal...

> On Mon, Oct 16, 2006 at 04:28:17PM +0100, Eric Eve wrote:
>>
>> <quic...@quickfur.ath.cx> wrote in message
>> news:20061014171912.GA8533@crystal...
>>
>> > On that note, I do want to see more automation in reconciling
>> > synonyms for actions, whether or not you feel like implementing
>> > it.
>> > :-) For example, RAISE FLAG should map to TURN CRANK ON
>> > FLAGPOLE if
>> > there's a flagpole with a crank in the current room, but should
>> > map
>> > to HOLD UP FLAG if I'm surrendering on a battlefield while
>> > holding a
>> > white flag. In other words, verbs may sometimes map to
>> > multiple
>> > actions, and which one is meant is decided based on context.
>>
>> I'd have thought this kind of thing was up to individual game
>> authors
>> to sort out; libraries and extensions can hardly be expected to
>> have a
>> sufficiently detailed knowledge of particular game worlds
>
> That's not my point at all; the point is that the context, which
> is game
> world dependent, is specified by the author, and based on this
> information the library maps verbs differently.

I don't follow how this can be "not your point at all", simply
because I suggest something might be better handled in game code
rather than library code (when it clearly seems to addressing the
same issue, unless we really are talking past each other here).

>> (many games won't have flags at all; those that do might use them
>> in
>> all sorts of different ways), while conversely any decent
>> existing IF
>> system will allow an author to vary what a command does according
>> to
>> context (it would be difficult to write decent IF without this
>> ability). So I'm not sure whether this amounts to much more in
>> practice than a plea for authors to be a bit smarter about
>> customising
>> the way some commands interact with some game objects.
>
> My point was that this customisation should be more automated than
> it
> currently is.

Perhaps you'd need to make your point a bit more specific to help me
to understand what you're actually driving at then. What kind of
automation would belong in a library to make it easier to customise
a game in this respect?


>> To expand just a little, I see it as the job of the general
>> parser (as
>> supplied by the library or an extension) to parse the player's
>> input
>> (RAISE FLAG, HOIST THE FLAG, RAISE THE GREEN FLAG or whatever) so
>> that
>> it resolves to, say, the Raise action and the greenFlag object
>> (after
>> taking into account scope and any other such considerations the
>> parser
>> uses to resolve ambiguity).
>
> Yes, this is what I was driving at.

Ah, so it turns out I haven't missed your point after all?

> How easy is it under the current TADS 3 system to do this?

Extremely. See below.

> AFAIK, if I want a non-standard verb as a synonym (e.g. "hoist") I
> have
> to actually go through the trouble of defining a Hoist verb, and
> possibly a HoistAction if I anticipate the verb 'hoist' to mean
> something else in another part of the game, and add remapTo()'s
> for
> different objects for which the action is possible.

That's right. Although the remaps could be added to classes if you
have a bunch of objects that behave the same way, to save
customizing a whole lot of objects the same way.

> I was hoping for a
> cleaner separation between verb and action, such that the author
> could
> simply list a set of verb rules and specify (somewhere) that they
> map to
> a certain action. E.g., something to the effect of:
>
> mapPhraseToAction [
> 'raise {greenFlag}',
> 'hoist {greenFlag}',
> 'turn {flagpoleCrank}',
> ... etc.
> ] -> [ RaiseAction, greenFlag ];

But apart from anything else (such as not being standard TADS 3
syntax) this doesn't look like it's performing the kind of context
checking you originally asked for.

> greenFlag : Thing {
> ...
> dobjFor(RaiseAction) { /* raise the flag */ }
> }
>
> and then somewhere else, you may have something like:
>
> mapPhraseToAction [
> 'hoist car [with crane]'
> 'lift car [with crane]'
> 'pick up car [with crane]'
> ...
> ] -> [ LiftWithAction, theCar, theCrane ];
>
> The library then collects all of these phrase mappings, and
> figures out
> that if the verb 'hoist' is used with an object, it should check
> whether
> the object is greenFlag or theCar, and map it to [RaiseAction,
> greenFlag] or [LiftWithAction, theCrane], respectively.

I'm not sure why this is significantly better than defining the
appropriate remappings on the greenFlag and theCar objects, which is
the way TADS 3 is designed to work. I suppose it would be possible
to define custom grammar tokens that matched the car object or the
flag object or whatever and then write custom grammar rules, but
again this would have to happen in the game rather than the library,
and it actually feels a more difficult way to achieve the same
object to me.

Well, it's pretty clean: you simply define different actions that
match different grammars:

Turn (as in TURN THE CRANK) is already defined in the standard
library, so you'd then define:

DefineIAction(TurnAround)
execAction()
{
"{You/he} turn{s} round. ";
}
;

VerbRule(TurnAround)
('turn' | 'spin') ('round' | 'around')
: TurnAroundAction
verbPhrase = 'turn/turning around'
;

DefineTopicAction(TurnInto)
execAction()
{
/* code for handling this */
}
;

VerbRule(TurnInto)
'turn' 'into' singleTopic
: TurnIntoAction
verbPhrase = 'turn/turning (into what)'
;

IOW TADS 3 already has a verb/action distinction built in. (So do
Inform and Hugo, though it works a little differently; the same is
probably true of other languages besides).

-- Eric


Richard Bos

unread,
Oct 16, 2006, 5:52:51 PM10/16/06
to
"Krister Fundin" <fun...@yahoo.com> wrote:

> "Richard Bos" <ral...@xs4all.nl> skrev i meddelandet

> > "Krister Fundin" <fun...@yahoo.com> wrote:
> >
> >> TAKE FIVE OF THEM APPLES AND PUT THOSE ON THAT
> >> TABLE.
> >
> > "Them apples"? That's bad English.
>
> Regional maybe -- I wouldn't know. My dictionary mentions this
> phrasing under possible uses for "them".

With an asterisk in front, I hope? It's not correct in any civilised
form of English.

> > Anyway, which "that" table? Just the single table that's present? Then
> > "the table" works just as well.
>
> Certainly. But someone could still conceivably type "that table", and
> there's no particular reason not to allow it.

And in fact "that table" appears to work in Inform 6, though I suspect
this is an accident of its parser rather than by design.

Richard

Richard Bos

unread,
Oct 16, 2006, 5:52:52 PM10/16/06
to
Andrew Plotkin <erky...@eblong.com> wrote:

> In rec.games.int-fiction, Eric Eve <eric...@nospamhmc.ox.ac.uk> wrote:
> >
> > "Nathan" <nts...@netscape.net> wrote in message
> > news:1161012770.9...@k70g2000cwa.googlegroups.com...
> > > I don't know whether this is a function of the parser *per se*, but
> > > I've always been bothered by games arbitrarily changing the
> > > antecedent of IT. This was a particular problem with Infocom
> > > games, but I've experienced it with recent games too.
> >
> > If it truly is arbitrary then it's likely to be annoying. Ideally a
> > parser should try to deduce what a player most likely means by IT in
> > terms of the last noun the player explicitly referred to.
>
> Inform 6 has long had a feature (and I'd rather put that in
> nasty-quotes) where IT refers to the last noun that the *game*
> explicitly referred to. So "inventory" and "look" change the referent.

> I believe Inform 7 has inherited that feature. It can be turned off,


> but since authors don't know about it, they don't consider the
> question.

It can also be turned off in Inform 6, by declaring MANUAL_PRONOUNS. I
don't know how many authors know about that. It's not in the DM4; IIRC
it was added in a later version of the library. It only turns off the
ittification of objects mentioned in inventories and room descriptions,
but that is enough to stop it from irritating me.

Richard

Steve

unread,
Oct 16, 2006, 11:04:24 PM10/16/06
to
Adam Thornton wrote:
> In article <1161016012.3...@k70g2000cwa.googlegroups.com>,
> Steve <steve...@yahoo.ca> wrote:
> >
> >Adam Thornton wrote:
> >> In article <1160780258.6...@b28g2000cwb.googlegroups.com>,
> >> <constantl...@gmail.com> wrote:
> >> >OH, and PLEASE DO NOT program your parsers in Intercal!
> >>
> >> ITYM, "PLEASE REFRAIN FROM progamming your parsers in INTERCAL!"
> >
> >WTF is wrong with Intercal? By all accounts it is a perfectly
> >reasonable language for general computing purposes. Sure, it may be a
> >little wierd, but that's just part of its charm.
>
> You have missed both the point and the joke. Also, name *one* such
> account.

The references fall under the category of 'personal correspondence',
but I assure you that the account is sound. I will have to contact a
few of the authors and see if they will mind if I post their testimony.
You don't mind waiting a little bit so I can properly support my
argument, do you?

> It's perfectly reasonable in the same sense that Brainf*ck is
> perfectly reasonable.

So long as it's between two consenting adults, I see no problem with
Brainf*cking.


Regards,

Steve

Adam Thornton

unread,
Oct 17, 2006, 12:45:24 AM10/17/06
to
In article <1161054263.9...@m7g2000cwm.googlegroups.com>,

Steve <steve...@yahoo.ca> wrote:
>The references fall under the category of 'personal correspondence',
>but I assure you that the account is sound. I will have to contact a
>few of the authors and see if they will mind if I post their testimony.
> You don't mind waiting a little bit so I can properly support my
>argument, do you?

Sure.

Note that I'm not disputing that you CAN write functional code in
INTERCAL. Merely that it is no more a suitable language for
understandable algorithmic expression than is Brainf*ck. Well, OK, a
*little* more.

It was, after all, I who gave the compiler for Object-Oriented INTERCAL
(on the late lamented assurdo.com, and I've never found the sources
anywhere else, and I don't think I kept a copy) its name: "oo, ick".
This was back in the days when embedded spaces and commas in file names
were still objects of horror, rather than Just Something Windows Users
Did So You'd Better Get Used To It.

Adam

Krister Fundin

unread,
Oct 17, 2006, 8:54:20 AM10/17/06
to

"Autymn D. C." <lysd...@sbcglobal.net> skrev i meddelandet
news:1161024267....@m73g2000cwd.googlegroups.com...

> I would like to anwrite the dictionary to take original and consistent
> ME, sheerly grammatic and literal-verbal input. 'go', for example,
> means "try". So 'go west' is verbally wrong because it means "try
> west". So I'd replace it with something like 'meet west' or 'see
> west', where "west" is anything. IOW, I want my own verbs.

Hm... Perhaps a trainable parser would be useful to this person, I.E.
one where you can mess with its grammar at runtime:

to meet is a verb
meet means go
meet west

Similarly, one could add missing synonyms and perhaps even classify
objects in various ways:

a book is a reading material
a newspaper is a reading material
take all the reading materials

Mostly a pointless gimmick though.

-- Krister Fundin

Krister Fundin

unread,
Oct 17, 2006, 9:16:42 AM10/17/06
to

"Benjamin Caplan" <celestial...@gmail.com> skrev i meddelandet
news:1160939790....@e3g2000cwe.googlegroups.com...

> So, players of interactive fiction, what kinds of annoyances and
> frustrations do you most often experience with the IF parser?

As for Inform games, there's one particular thing that has always
annoyed me: that they don't understand PUT THE HAT ON. It's like
a big black hole in the grammar definitions. Also, ISTR that commands
such as TAKE THE HAT AND WEAR IT don't work too well.

As for TADS 3 games, one thing that's come up a few times is the
parsing of disambiguation responses in cases like this one:

> READ BOOK
Which book do you mean, the book on the shelf or the book on the
desk?

Here, I have a tendency to just write "desk", which the parser doesn't
accept. You have to write "the one on the desk" or somesuch. It would
be nice if the answer could be treated the same way as a SpecialTopic as
a last resort.

-- Krister Fundin

Autymn D. C.

unread,
Oct 17, 2006, 12:11:34 PM10/17/06
to
dr west

don, doff, both, all

JDC

unread,
Oct 17, 2006, 2:23:06 PM10/17/06
to

Krister Fundin wrote:
> Hm... Perhaps a trainable parser would be useful to this person, I.E.
> one where you can mess with its grammar at runtime:
>
> to meet is a verb
> meet means go
> meet west
>
> Similarly, one could add missing synonyms and perhaps even classify
> objects in various ways:
>
> a book is a reading material
> a newspaper is a reading material
> take all the reading materials
>
> Mostly a pointless gimmick though.

Actually, this might be kind of neat if the game could be set up to
read these synonyms from a file. Then each player could set up his own
aynonym file and have it loaded every time he played a game. I could
see this being particularly useful for playing a game which was not in
your native language. Someone could create a mapping of the most common
verbs from various languages (actually, I think someone proposed this
in another thread a while back). If you know enough of a language to be
able to read the output (with a dictionary, perhaps), it can still be
difficult to remember the words for a command you want to enter...

-JDC

quic...@quickfur.ath.cx

unread,
Oct 18, 2006, 1:29:16 AM10/18/06
to

OK, I didn't make myself clear then. What I meant was that I'd like to
see more *automation* in specifying how to deal with these alternative
phrasings. The current approach involves creating new verbs and then
associating said verbs with actions, possibly remapping verbs for
certain objects, etc.. What I'd prefer is if the author could simply
say something to the effect of "RAISE FLAG should be synonymous to TURN
CRANK ON FLAGPOLE", and the library figures out that it should create a
new verb for "RAISE", and map that to TURN CRANK ON FLAGPOLE when the
flagpole is in context. Then when the betatesters come back to the
author and asks for another alternate phrasing, the author doesn't have
to create a brand new verb, add a new action, and possibly putting more
remap's into existing objects. All he has to do is to state the
alternate phrasing, and the library takes care of creating the necessary
mappings.


[...]


> >> To expand just a little, I see it as the job of the general parser
> >> (as supplied by the library or an extension) to parse the player's
> >> input (RAISE FLAG, HOIST THE FLAG, RAISE THE GREEN FLAG or
> >> whatever) so that it resolves to, say, the Raise action and the
> >> greenFlag object (after taking into account scope and any other
> >> such considerations the parser uses to resolve ambiguity).
> >
> > Yes, this is what I was driving at.
>
> Ah, so it turns out I haven't missed your point after all?

Well, my point is that this process can be made much more convenient.


> > How easy is it under the current TADS 3 system to do this?
>
> Extremely. See below.
>
> > AFAIK, if I want a non-standard verb as a synonym (e.g. "hoist") I
> > have to actually go through the trouble of defining a Hoist verb,
> > and possibly a HoistAction if I anticipate the verb 'hoist' to mean
> > something else in another part of the game, and add remapTo()'s for
> > different objects for which the action is possible.
>
> That's right. Although the remaps could be added to classes if you
> have a bunch of objects that behave the same way, to save customizing
> a whole lot of objects the same way.

It still seems awkward to me. I mean, the current system does work, but
every time you want to add a new alternate phrasing, you have to go
through the process of defining a new verb and specifying a new action
(and modifying class Thing to handle default cases, etc.). What I'd like
to be able to do is, for some object X, specify a set of phrases
(involving that object) that maps to some action A on the object. I
don't want to care if the same verb is used elsewhere; the library
should notice that some phrases across objects share the same lexical
verb, and do the necessary mappings/remappings to handle those cases.


> > I was hoping for a cleaner separation between verb and action, such
> > that the author could simply list a set of verb rules and specify
> > (somewhere) that they map to a certain action. E.g., something to
> > the effect of:
> >
> > mapPhraseToAction [
> > 'raise {greenFlag}',
> > 'hoist {greenFlag}',
> > 'turn {flagpoleCrank}',
> > ... etc.
> > ] -> [ RaiseAction, greenFlag ];
>
> But apart from anything else (such as not being standard TADS 3
> syntax) this doesn't look like it's performing the kind of context
> checking you originally asked for.

The context checking comes in when you have these phrases for multiple
objects, some of which may share the same lexical verbs (or nouns,
whichever is the case). The author shouldn't have to worry about the
fact that two different actions on two different objects happen to use
the same word to refer to the action, and so have to define the verb and
specify remappings a certain way. The library should collect all the
phrases listed for every object, sort through them, and realize that
some verb V is being used multiple times in different contexts, and so
create the necessary verb definitions and remappings for the objects in
question. This will be done in such a way that when the player uses the
verb V in different contexts, it gets mapped to the appropriate actions
as specified by the author.


> > The library then collects all of these phrase mappings, and figures
> > out that if the verb 'hoist' is used with an object, it should check
> > whether the object is greenFlag or theCar, and map it to
> > [RaiseAction, greenFlag] or [LiftWithAction, theCrane],
> > respectively.
>
> I'm not sure why this is significantly better than defining the
> appropriate remappings on the greenFlag and theCar objects, which is
> the way TADS 3 is designed to work. I suppose it would be possible to
> define custom grammar tokens that matched the car object or the flag
> object or whatever and then write custom grammar rules, but again this
> would have to happen in the game rather than the library, and it
> actually feels a more difficult way to achieve the same object to me.

The advantage to this method is that the author can potentially specify
a LOT of alternate phrasings for the same action easily. Haven't we all
encountered some game X where we knew what action to take, but the
author never thought of the way we phrased it, and so we have to guess a
phrasing that the game understood? Some of these actions can be phrased
in so many ways that it becomes very tedious for the author to account
for them all---he has to define 20 new verbs for every other action in
the game, each of which involves non-trivial amounts of code. (And then
he has to worry about what to do if those new verbs are applied to
objects that he didn't intend them to.) By having the library infer the
verb definitions and remaps automatically (as much as is possible), the
author can simply add new phrasings by adding a single line of code. It
leaves more time for the author to think about the game instead of
struggling with tedious code.


[...]


> > Or maybe there's already a clean way of doing this and I'm just
> > speaking out of ignorance.
>
> Well, it's pretty clean: you simply define different actions that
> match different grammars:
>
> Turn (as in TURN THE CRANK) is already defined in the standard
> library, so you'd then define:
>
> DefineIAction(TurnAround)
> execAction()
> {
> "{You/he} turn{s} round. ";
> }
> ;
>
> VerbRule(TurnAround)
> ('turn' | 'spin') ('round' | 'around')
> : TurnAroundAction
> verbPhrase = 'turn/turning around'
> ;
>
> DefineTopicAction(TurnInto)
> execAction()
> {
> /* code for handling this */
> }
> ;
>
> VerbRule(TurnInto)
> 'turn' 'into' singleTopic
> : TurnIntoAction
> verbPhrase = 'turn/turning (into what)'
> ;
>
> IOW TADS 3 already has a verb/action distinction built in. (So do
> Inform and Hugo, though it works a little differently; the same is
> probably true of other languages besides).

[...]

True, so it does have the facility for doing this. Still, I think that a
lot of this could be automated more than it currently is.


QF

--
Life is too short to run proprietary software. -- Bdale Garbee

Emily Short

unread,
Oct 18, 2006, 2:21:59 AM10/18/06
to

quic...@quickfur.ath.cx wrote:
> OK, I didn't make myself clear then. What I meant was that I'd like to
> see more *automation* in specifying how to deal with these alternative
> phrasings. The current approach involves creating new verbs and then
> associating said verbs with actions, possibly remapping verbs for
> certain objects, etc.. What I'd prefer is if the author could simply
> say something to the effect of "RAISE FLAG should be synonymous to TURN
> CRANK ON FLAGPOLE", and the library figures out that it should create a
> new verb for "RAISE", and map that to TURN CRANK ON FLAGPOLE when the
> flagpole is in context.

That's an attractive idea, but it leaves a fair number of things
unspecified. Are we just matching the literal text "raise flag", or is
"flag" a thing in the game? If so, does it have to be in scope? Should
the game understand "raise [something else]" at all? If so, what will
be the default message when the player tries to raise something that
doesn't have this mapping? And so on.

Not saying there couldn't be any improvement on the way this is
currently handled in various languages, but it would be hard to make it
*quite* as automatic as you're suggesting, I think.

Eric Eve

unread,
Oct 18, 2006, 4:17:12 AM10/18/06
to

<quic...@quickfur.ath.cx> wrote in message
news:20061018052933.GA27135@crystal...

> OK, I didn't make myself clear then. What I meant was that I'd
> like to
> see more *automation* in specifying how to deal with these
> alternative
> phrasings. The current approach involves creating new verbs and
> then
> associating said verbs with actions, possibly remapping verbs for
> certain objects, etc.. What I'd prefer is if the author could
> simply
> say something to the effect of "RAISE FLAG should be synonymous to
> TURN
> CRANK ON FLAGPOLE", and the library figures out that it should
> create a
> new verb for "RAISE", and map that to TURN CRANK ON FLAGPOLE when
> the
> flagpole is in context. Then when the betatesters come back to the
> author and asks for another alternate phrasing, the author doesn't
> have
> to create a brand new verb, add a new action, and possibly putting
> more
> remap's into existing objects. All he has to do is to state the
> alternate phrasing, and the library takes care of creating the
> necessary
> mappings.

I'm now not quite sure at what level you want this intervention; as
Emily asks in a separate post, what would you want to happen to
RAISE X (where X != flag), and are you wanting the parser to act on
the flag object or the string "flag". If the latter you could simply
do what you wanted with a StringPreParser:

StringPreParser
doParsing (str, which)
{
if(str.toLower == 'raise flag'
&& gPlayerChar.canTouch(flagPole))
return 'turn crank on flagpole';
return str;
}
;

And if that's all you wanted, you could probably write a macro so
that an author could express it a good deal more concisely, roughly
along the lines you suggest; e.g. it might be compressible to
something like:

changeCommand('raise flag', 'turn crank on handle',
gPlayerChar.canTouch(flagPole))

But this doesn't test for the flag being in scope, or for other ways
in which the player might refer to the flag. It may be someone can
come up with a syntactic short-cut that handles all this too, but to
do the job properly you have to make sure the library performs the
same kind of checks it already does, and to cut across that may risk
breaking the system. Part of the problem is that the TADS 3 parser
doesn't attempt to resolve noun phrases to objects until it's
resolved the entire phrase to an action, so unless RAISE resolves to
some action, the parser can't go on to check whether the noun phrase
entered by the player resolves to the flag object, which itself
involves not only checking whether the flag object is in scope but
whether it's the most logical available target for a 'raise'
command. Short-circuiting these steps may be possible, but unless
you're very careful, it may not be such a good idea, and may end up
being more trouble than it's worth. The problem may in any case be
somewhat more complex than you're allowing for.

> It still seems awkward to me. I mean, the current system does
> work, but
> every time you want to add a new alternate phrasing, you have to
> go
> through the process of defining a new verb and specifying a new
> action
> (and modifying class Thing to handle default cases, etc.). What
> I'd like
> to be able to do is, for some object X, specify a set of phrases
> (involving that object) that maps to some action A on the object.
> I
> don't want to care if the same verb is used elsewhere; the library
> should notice that some phrases across objects share the same
> lexical
> verb, and do the necessary mappings/remappings to handle those
> cases.

Not necessarily; if the alternative phrasing is simply a synonym for
an existing one, you simply define the new phrasing. For example, if
you want to allow INSERT X INTO X to mean the same as PUT X IN Y,
then in TADS 3 you'd simply write:

modify VerbRule(PutIn)
('put' | 'insert') dobjList ('in'| 'into') singleIobj:
;

You only need to go through defining a new Action and a new VerbRule
and then modifying Thing etc. if you're defining a totally new
Action; you don't need it to do all that just for synonyms. On the
other hand, if you are defining a completely new Action (say Raise)
you probably do need to define it properly, since if players find
that RAISE FLAG works they may well try RAISE HANDS or RAISE SHIELD
or RAISE CHILDREN, and the parser (or rather, your game) ought to
handle such attempts gracefully (or wittily, as the case may be),
and certainly not by telling players that "The word 'raise' is not
needed in this game" or "I don't understand your command" or some
such equivalent, which is what you'll probably get if you don't go
to the bother of carrying out all the necessary steps.

IOW, automation is not such a good thing if it encourages authors
not to take steps they really need to take to ensure a polished
product.

But I think I'm simply amplifying Emily's points here.

-- Eric


Matthew Slattery

unread,
Oct 18, 2006, 3:12:06 PM10/18/06
to
Adam Thornton <ad...@fsf.net> wrote:
> It was, after all, I who gave the compiler for Object-Oriented INTERCAL
> (on the late lamented assurdo.com, and I've never found the sources
> anywhere else, and I don't think I kept a copy) its name: "oo, ick".

http://homepages.nildram.co.uk/~intercal/

-- Matthew.

Jan Thorsby

unread,
Oct 18, 2006, 9:34:31 PM10/18/06
to
I haven't read this whole thread; this is concerning the original question.
How bout before one stars to make a game, one could fill out a form about
what standard commands one would like to have in the game, just tick off a
YES box or a NO box. (Or occasionally there could be alternative grammars
for commands one could choose between.) That way there could be lots of
semi-standard commands, but without all writers having to worry about them.
And for people who can't be bothered to fill out the form, it is set to the
normal standard verbs.


quic...@quickfur.ath.cx

unread,
Oct 18, 2006, 10:03:00 PM10/18/06
to
On Tue, Oct 17, 2006 at 11:21:59PM -0700, Emily Short wrote:
>
> quic...@quickfur.ath.cx wrote:
> > OK, I didn't make myself clear then. What I meant was that I'd like
> > to see more *automation* in specifying how to deal with these
> > alternative phrasings. The current approach involves creating new
> > verbs and then associating said verbs with actions, possibly
> > remapping verbs for certain objects, etc.. What I'd prefer is if
> > the author could simply say something to the effect of "RAISE FLAG
> > should be synonymous to TURN CRANK ON FLAGPOLE", and the library
> > figures out that it should create a new verb for "RAISE", and map
> > that to TURN CRANK ON FLAGPOLE when the flagpole is in context.
>
> That's an attractive idea, but it leaves a fair number of things
> unspecified. Are we just matching the literal text "raise flag", or is
> "flag" a thing in the game?

FLAG is a thing in the game. Literal matching comes with a lot of
problems, as you & Eric point out.


> If so, does it have to be in scope?

Yes, otherwise it wouldn't make sense to refer to it. You'd probably get
a message along the lines of "you don't see a flag here".


> Should the game understand "raise [something else]" at all? If so,
> what will be the default message when the player tries to raise
> something that doesn't have this mapping? And so on.

A default message would do, I suspect. "You can't raise a [thing]" or
something along those lines.


> Not saying there couldn't be any improvement on the way this is
> currently handled in various languages, but it would be hard to make
> it *quite* as automatic as you're suggesting, I think.

I'm not expecting it to be easy. :-) But I'd like to throw in some ideas
about how one might go about implementing such a thing, so that we work
towards it.


QF

--
Who told you to swim in Crocodile Lake without life insurance??

Neil Cerutti

unread,
Oct 18, 2006, 10:09:42 PM10/18/06