Jacek's Christmas gift wish

122 views
Skip to first unread message

Jacek Pudlo

unread,
Dec 8, 2000, 3:13:12 PM12/8/00
to
Here's what I would like to find in my Christmas stocking. A parser. But not
just any ordinary, run of the mill mediocre parser. The parser I want should
be able to handle multiple verbs ("get mushroom and eat it"), multiple
direct and indirect objects ("examine banknote and bill with magnifying
glass and ultra violet lamp"), it should also be able to distinguish nouns
from adjectives. It should be able to make intelligent scope decissions.
When I type "follow captain" I do not want to read "you are still sitting in
the chair". When I type "close door" it should be able to infer that I'm
referring to the open door and not the other door, that is currently closed.

Will such a parser ever become reality?


Magnus Olsson

unread,
Dec 8, 2000, 4:05:50 PM12/8/00
to
In article <shbY5.2279$Kd1.3...@newsb.telia.net>,

Well, some of these things are quite easy to do with the Inform
parser: distinguishing nouns from adjectives, preferring open doors
to closed ones when trying to close one, automatically getting out
of the chair when following the captain (though the last thing is
more a feature of the world model than the parser proper).

I'll pass on "intelligent scope decissions" [sic] since I'm not
sure what you mean...

As for multiple direct and indirect object, I think that's also
a question of the world model. Currently, Inform handles multiple
direct objects by calling the action routine for each object:

"examine banknote and bill with magnifying glass" ->
<< examine banknote magnifying_glass >>;
<< examine bill magnifying_glass >>;

But what do you do if you have multiple indirect objects? Call
a one-indirect-object action routine once for each object, like
<< examine banknote magnifying_glass >>;
<< examine banknote uv_lamp >>;

or, which might be more appropriate in this case, do you call a
multiple-indirect-object action routine, like this:
<< examine banknote magnifying_glass uv_lamp>>; ?

That is, should the command be parsed as having two separate
indirect objects (i.e. as an ellipsis for two commands), or
as having one, composite, indirect object?

--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------

Andrew MacKinnon

unread,
Dec 8, 2000, 6:25:12 PM12/8/00
to

The best parser in that respect is Inform, followed by TADS. You will
need a lot of tricky programming to do some of that stuff.

- Multiple verbs ("get mushroom and eat it"): How does the parser know
that you aren't taking "mushroom" and "eat it"?

- Multiple direct & indirect objects: Don't need it. Even with direct
object only plural the thing looks clumsy:
pencil: Taken.
pen: Taken.

That would require tricks. (The prefixing object names is hard-coded
into the library).

- Distinguish nouns from adjectives: parse_name to the rescue! Here's my
basic noun-required routine:

parse_name
[w i p; w=NextWord();
while(w=='toilet' or 'paper')
{i++; if (w=='paper') p=1; w=NextWord();
}
if (p==1) return i;
],

For more examples go to:
http://www.geocities.com/andrew_mackinnon_2000/informtips-1.html

- Scope decisions. Those aren't very useful.

- Tedious actions. Use coding in before routines. An example is having
to open the pop before drinking it. This can be solved with coding in a
before routine:

before
[; Drink: if (ObjectIsUntouchable(self)==1) rtrue;
if (self hasnt open)
{give self open; print "(opening the pop can)^";
}
remove self;
"You drink the pop all the way through and dispose of it.";
],

This is simple.

- Referring to objects and sensible objects. See the Designer's Manual
for ways to use ChooseObjects for this purpose.

Doors can become a lot easier if you have them automatically open. I
have made a library called easydoors.h which is available at:

If it's still in the incoming dir:
ftp://ftp.gmd.de/incoming/if-archive/easydoors.h
If it's been put in it's correct place:
ftp://ftp.gmd.de/programming/inform6/library/contributions/easydoors.h
Anytime:
http://members.v3space.com/andrewmackinnon/easydoors.h

--
Andrew MacKinnon
http://www.geocities.com/andrew_mackinnon_2000/
(Please remove NOSPAM from e-mail address above)

Andrew Hunter

unread,
Dec 8, 2000, 10:13:00 PM12/8/00
to
In article <3A316DEA...@hotmailNOSPAM.com>, Andrew MacKinnon wrote:
>Jacek Pudlo wrote:
>>
>> Here's what I would like to find in my Christmas stocking. A parser. But not
>> just any ordinary, run of the mill mediocre parser. The parser I want should
>> be able to handle multiple verbs ("get mushroom and eat it"), multiple
>> direct and indirect objects ("examine banknote and bill with magnifying
>> glass and ultra violet lamp"), it should also be able to distinguish nouns
>> from adjectives. It should be able to make intelligent scope decissions.
>> When I type "follow captain" I do not want to read "you are still sitting in
>> the chair". When I type "close door" it should be able to infer that I'm
>> referring to the open door and not the other door, that is currently closed.
>>
>> Will such a parser ever become reality?
>
>The best parser in that respect is Inform, followed by TADS. You will
>need a lot of tricky programming to do some of that stuff.
>
>- Multiple verbs ("get mushroom and eat it"): How does the parser know
>that you aren't taking "mushroom" and "eat it"?

Hum, we did this a while back. http://www.logicalshift.co.uk/etc/ has
a patched (inform) parser that can handle this and many other cases through
backtracking. Basically it knows because 'eat it' isn't a valid
object. The normal parser just gives up, and the patched parser goes
back and tries "get mushroom then eat it". Where there is a real ambiguity,
the object is assumed. ('get dress and duck' in my example game...)

Given the choice of example, I suspect Jacek already knows this, however ;-)

[ SNIP ]

Can a better parser exist, though? Well, yes... A recursive descent parser
would find a (possibly ambiguous) pattern match if one existed (which
the Inform parser doesn't always do). A GLR parser would find all possible
pattern matches, and give you an opportunity to pick which one is most
sensible. Implementing either than these would require a little more than
a quick hack to the standard library, though. I think a rec-descent parser
could be done without hacking the compiler itself, but a GLR one would
require a new approach to the grammar tables. The GLR parser would probably
be faster when there's little ambiguity, however (best case is as fast as
an ordinary LR parser, worst case is exponential time [and space]). GLR*
parsers (a noise-skipping version of the GLR parser) are commonly used in
natrual language parsing projects such as JANUS.

Now, I happen to have about half a GLR parser generator that I wrote a while
back sitting on my hard disc... Hmph, shame the Inform licence forbids the
distribution of 'substantially modified' copies.

Andrew.

--
____
\ \ \ Andrew Hunter <and...@logicalshift.co.uk>
> > > http://www.logicalshift.co.uk (me)
/_/_/ http://www.impulse.org.uk (impulse)

qkho...@my-deja.com

unread,
Dec 8, 2000, 10:19:57 PM12/8/00
to
In article <3A316DEA...@hotmailNOSPAM.com>,

Andrew MacKinnon <andre...@hotmailNOSPAM.com> wrote:
> - Multiple direct & indirect objects: Don't need it.

Although some cases like the following can be written by inventing new
verbs:

affix the note on the door with pin.
-> pin the note on the door.
throw stone with sling at the bad guy
-> sling the stone at the bad guy

I do not think you can necessarily use that trick to eliminate the need
for multiple indirect objects. For example, I do not think of a good
way to rewrite the example original poster gave, examining the banknote
with magnifying glass under UV light.

Sent via Deja.com http://www.deja.com/
Before you buy.

J. Robinson Wheeler

unread,
Dec 9, 2000, 2:59:01 AM12/9/00
to
Andrew MacKinnon wrote:
>
> Jacek Pudlo wrote:
> >
> > The parser I want should be able to handle multiple verbs ("get
> > mushroom and eat it"), multiple direct and indirect objects
> > ("examine banknote and bill with magnifying glass and ultra
> > violet lamp"), it should also be able to distinguish nouns
> >from adjectives.
>
> The best parser in that respect is Inform, followed by TADS. You will
> need a lot of tricky programming to do some of that stuff.
>
> - Distinguish nouns from adjectives: parse_name to the rescue! Here's my
> basic noun-required routine:

TADS already distinguishes between nouns and adjectives; each is a
distinct object property. The parser knows the difference.

--
J. Robinson Wheeler http://thekroneexperiment.com
whe...@jump.net

Steven Howard

unread,
Dec 9, 2000, 12:20:37 PM12/9/00
to
In <90s8cq$mn7$1...@nnrp1.deja.com>, on 12/09/00
at 03:19 AM, qkho...@my-deja.com said:

>I do not think you can necessarily use that trick to eliminate the
>need for multiple indirect objects. For example, I do not think of a
>good way to rewrite the example original poster gave, examining the
>banknote with magnifying glass under UV light.

Does the character have three hands? If not, then there's no reason
not to require something like:

>TURN ON UV LAMP
>EXAMINE BANKNOTE WITH MAGNIFYING GLASS

========
Steven Howard
mrb...@earthlink.net
http://home.earthlink.net/~mrblore


Neil K.

unread,
Dec 10, 2000, 3:39:52 AM12/10/00
to
Andrew MacKinnon wrote:
> The best parser in that respect is Inform, followed by TADS. You will
> need a lot of tricky programming to do some of that stuff.

Why is Inform necessarily better here? Most of the previous suggestions
are already supported by TADS or can be implemented using it.

Jacek Pudlo wrote:

> Here's what I would like to find in my Christmas stocking. A parser. But not
> just any ordinary, run of the mill mediocre parser. The parser I want should
> be able to handle multiple verbs ("get mushroom and eat it"), multiple
> direct and indirect objects ("examine banknote and bill with magnifying
> glass and ultra violet lamp"), it should also be able to distinguish nouns
> from adjectives. It should be able to make intelligent scope decissions.
> When I type "follow captain" I do not want to read "you are still sitting in
> the chair". When I type "close door" it should be able to infer that I'm
> referring to the open door and not the other door, that is currently closed.

Many of these things aren't really part of the parser, per se, but the
whole IF system's framework. But a few of these requests really come down
to how much work you, the author, want to put into the work. It's not
easily to generalize tons of functionality into the default libraries and
so Graham and Mike have instead provided reasonable feature sets rather
than going overboard. Having said that:

- TADS supports "get mushroom and eat it."

- This is the one exception where it's easier to hack Inform. TADS 2 does
not support multiple indirect objects. This would have to wait for T3, if
you think it's important.

- TADS has always distinguished nouns from adjectives and it's a good thing.

- What sort of intelligent scope decisions? Both TADS and Inform let you
code a lot of stuff if you want to.

- TADS already supports choose appropriate objects of the "close door"
variety outlined above. The mechanism can be extended, albeit with a
little work on the part of the author, to do more fancy tricks. For
example, in my unfinished game you can do this when not holding a bottle:

>drink beer
(picking up and opening the beer bottle first, the cap popping off into
your hand.)

It was extra work for me, but I think it's good for the player.

- Neil K.

John Bytheway

unread,
Dec 10, 2000, 3:57:02 PM12/10/00
to
> - TADS has always distinguished nouns from adjectives and it's a good
thing.

I agree in theory, but my lazy side must point out that i like to be able to
do this:

The Bedroom
You see a tall wardrobe (which is closed) here.
>OPEN TALL

This makes no sense - but I do it all the time becaus I know how the insides
of inform work, and thus I expect it to work. I'm always shocked when
playing TADS to find that it doesn't.

> >drink beer
> (picking up and opening the beer bottle first, the cap popping off into
> your hand.)

I would _never_ think of trying to do something like that - I'm sufficiently
lazy that I assume everyone else is to lazy to implement such things... I
wouldn't be a very good beta tester, I suppose.

John


Andrew MacKinnon

unread,
Dec 10, 2000, 4:18:45 PM12/10/00
to

I believe that the following only will work with TADS:

<1 or more adjectives><1 noun>
<1 noun>
<1 or more adjectives>

but *NOT* <1 noun><1 or more adjectives>

I believe you can refer to anything by an adjective in this way.

--
Andrew MacKinnon
andrew_mac...@yahoo.com
http://www.geocities.com/andrew_mackinnon_2000/

John Bytheway

unread,
Dec 10, 2000, 5:54:57 PM12/10/00
to
> I believe that the following only will work with TADS:
>
> <1 or more adjectives><1 noun>
> <1 noun>
> <1 or more adjectives>
>
> but *NOT* <1 noun><1 or more adjectives>
>
> I believe you can refer to anything by an adjective in this way.
I think you're right... my bad experiences were probably due to lack of
adjective properties.

John


Neil K.

unread,
Dec 10, 2000, 8:14:41 PM12/10/00
to
"John Bytheway" <john.b...@btinternet.com> wrote:

> I agree in theory, but my lazy side must point out that i like to be able to
> do this:
>
> The Bedroom
> You see a tall wardrobe (which is closed) here.
> >OPEN TALL
>
> This makes no sense - but I do it all the time becaus I know how the insides
> of inform work, and thus I expect it to work. I'm always shocked when
> playing TADS to find that it doesn't.

It does and it doesn't.

It only doesn't work if "tall" is defined somewhere in the game as a
noun. If it isn't, then referring to an object by just an adjective works
fine.

- Neil K.

Reply all
Reply to author
Forward
0 new messages