Inform in other languages

Showing 1-87 of 87 messages
Inform in other languages NEIL SLATER 5/19/96 12:00 AM

Kees wrote:

KW> Maybe there is a way to evaluate input sentences not in the way Inform
KW> does, which basically is in a linear way starting with the first word
KW> cutting down a tree of choices, and then taking the second word.
KW> Actually, I don't think it can be done in another way. Who knows?

There are probably lots of ways do parse input. There may be some experts
on this lurking in comp.ai.games, it might be worth a try.

If I were to design a parser nowadays (which I could well be doing), I
would write an algorithm something like this:

1. Identify all words in the sentence from a dictionary. The dictionary
also assigns them a _type_ eg Article, Noun, Verb, Preposition. (This is
already failing as a natural language interpreter, but should be adequate
for an adventure)

eg "use the key to unl the red doo" becomes
   "use" "the" "key" "to" "unlock" "the" "red" "door", stored in an array.
and  ^V    ^R     ^N  ^P       ^V     ^R   ^A     ^N for types in an
array. (R stands for "aRticle")

2. Assign all Adjectives to the respective Nouns to make "Things" (I don't
want to use the word "Object", my sense of grammer is already bad :-).
Collapse the sentence, so that there are no Nouns or Adjectives. (You can
use this to search your game database later.)

eg the example becomes
   "use" "the" "key" "to" "unlock" "the" "red door", stored in an array.
     ^V    ^R    ^T   ^P       ^V    ^R         ^T

3. Strip out all "Articles" that are in front of "Things". (Actually, I
normally cheat, and strip out all articles, but that might annoy the
purists who want to get an error message when they type "the take the red
the a the key")

eg "use" "key" "to" "unlock" "red door"
     ^V    ^T   ^P       ^V         ^T

4. Run through a list of "order templates", to map the sentence into a
standard format, that can be used by the rest of the adventure program.

This requires a little more explanation. A "template" might be something
like "V(*)T1(*)P(to)T2(*) - V(*)T1(*)P(to)T2(*)". What this is saying is
that any sentence that goes "Verb thing to thing" will be mapped to "Verb
thing to thing" ("Give rock to troll"). Seems like a waste of time? Well,
that example allows the parser to know when to stop searching and go on to
the next stage.

eg the example might match "V1(use)T1(*)P(to)V2(*)T2(*) -
V2(*)T2(*)P(with)T1(*)", giving a more standard
"unlock" "red door" "with" "key".

* is a wildcard ie matches all possible words, in case you wondered

5. Once this has been done, a more traditional adventure parser can be used
to check the "sense" of the order, with the added advantage that you know
the input has been "Tidied" considerably.

I cut "5" and beyond short, cause I realized that I am straying a lot off
topic, and this ought to be in rec.programming.if (if it exists?).

For translating Dutch and other languages for i-f, maybe something
like step 4 could be of some use. For a quick and dirty attempt, you could
still use English as the "internal" language, and map commands from one
language to another using some kind of pattern matching. You may need to
sub-type your verbs to do this properly (I only know very little Dutch
Grammar).

For example, "Grijp het rode sleutel" has exactly the same grammer as
"Get the red key", so you could use the template "V(*)T(*) - V(*)T(*)".
"Gebruik de sleutal om de deur op slot te doen" is in a different order to
"use the key to lock the door", but you could map it using something like
"V(gebruik)T1(*)P(om)T2(*)V2(*) - V2(*)T2(*)P(with)T1(*)". I am not sure
if this would apply for all uses of "gebruik", and you have some trouble
with "slot te doen", but perhaps it's a start?

Well, I hope I haven't bored you all too much with programming,

Bye,

Neil.
---
 * RM 1.3 U0448 * Neil....@Almac.co.uk

Inform in other languages, part 2 John Wood 5/19/96 12:00 AM

In article: <8C0E29E.0512...@almac.co.uk>  neil....@almac.co.uk (NEIL SLATER)
writes:

> If I were to design a parser nowadays (which I could well be doing), I
> would write an algorithm something like this:
>
> 1. Identify all words in the sentence from a dictionary. The dictionary
> also assigns them a _type_ eg Article, Noun, Verb, Preposition. (This is
> already failing as a natural language interpreter, but should be adequate
> for an adventure)
>
> eg "use the key to unl the red doo" becomes
>    "use" "the" "key" "to" "unlock" "the" "red" "door", stored in an array.
> and  ^V    ^R     ^N  ^P       ^V     ^R   ^A     ^N for types in an
> array. (R stands for "aRticle")

This stage is actually more of a problem than you might think,
because many words cannot be unambiguously identified in this way.

One silly example that Magnetic Scrolls used to advertise their parser
was the player input

 >PLANT THE POT PLANT IN THE PLANT POT.

What can you do with this?  You may say it's an unrealistic example,
but this sort of problem crops up in smaller ways all over the place:

 >LOCK DOOR
 Whick lock do you mean, the verb or the padlock?

or even

 >N
 Which north do you mean, the verb, the north door, or the north wall?

Obviously, you wouldn't let things get this far, but if you don't look
at the structure before identifying the parts you are going to run into
these sorts of problems.

I guess I'm just saying you shouldn't gloss over this stage as it's
vital to the way your parser works - I for one would be interested in a
solution to this problem that doesn't force an author to avoid nouns
which are also verbs or adjectives.

John


Inform in other languages, part 2 L.J. Wischik 5/19/96 12:00 AM

[What about the case where a word can be, say, both a noun and an
 adjective]

John Wood  <jo...@elvw.demon.co.uk> wrote:
>I guess I'm just saying you shouldn't gloss over this stage as it's
>vital to the way your parser works - I for one would be interested in a
>solution to this problem that doesn't force an author to avoid nouns
>which are also verbs or adjectives.

Don't you just tag the word as both; and when parsing the sentence, you
keep active a list of all possible constructions that could have lead you
to either possibility? Somewhere in my past I remember an algorithm by
Knuth (I think... but then it's probably a safe bet) used for matching
templates over a tree of abstract assembly code in such a way as to
optimise the instructions for a particular architecture and for cost or
size or something. I'd have imagined something similar to this.

--
Lucian

Inform in other languages, part 2 Dan Shiovitz 5/20/96 12:00 AM

In article <203820...@elvw.demon.co.uk>,

John Wood  <jo...@elvw.demon.co.uk> wrote:
>In article: <8C0E29E.0512...@almac.co.uk>  neil....@almac.co.uk (NEIL SLATER)
>writes:
>> If I were to design a parser nowadays (which I could well be doing), I
>> would write an algorithm something like this:
[..]

> >LOCK DOOR
> Whick lock do you mean, the verb or the padlock?
>
>or even
>
> >N
> Which north do you mean, the verb, the north door, or the north wall?
>
>Obviously, you wouldn't let things get this far, but if you don't look
>at the structure before identifying the parts you are going to run into
>these sorts of problems.
>
>I guess I'm just saying you shouldn't gloss over this stage as it's
>vital to the way your parser works - I for one would be interested in a
>solution to this problem that doesn't force an author to avoid nouns
>which are also verbs or adjectives.
Possibly I'm just obtuse, but it seems to me there's a terribly simple
solution.  Namely, look at word position.  The first word in the line will
always be either a verb, or if it's immediately followed by a comma, then it's
a noun, in which case the comma will be followed by a verb.  You maintain
lists of verbs, nouns, adjectives, etc, and each time you come to a word whose
position makes it out to be an X, then you look it up in the appropriate list.
For instance, take the sentence LOOK AT THE BALL.  The first word is a verb,
so we look it up in our verb-list and it's there.  We proceed to the next
word, which follows a verb, so it's either a noun, an adjective, a definitive-
marker (or whatever you call an "a" or a "the"), or a preposition.
We test out the theory of it being a noun, an adjective, or a definitive-
marker, but those all hang up on the fact that the third word is a definitive-
marker, and that only comes at the start of a word.  So we conclude that the
second word is a preposition.  The third word is a definitive-marker, and
the fourth word is either an adjective or a noun, but the sentence needs a
noun if this were to be an adjective, therefore it's a noun.  Ok, so this
example is apallingly, but it seems workable enough if someone were to put
more than five minutes into it.  So what am I missing?

>John
--
dan shiovitz scy...@u.washington.edu sh...@cs.washington.edu
slightly lost author/programmer in a world of more creative or more sensible
people ... remember to speak up for freedom because no one else will do it
for you: use it or lose it ... carpe diem -- be proactive.
my web site: http://weber.u.washington.edu/~scythe/home.html some ok stuff.

Inform in other languages, part 2 unknown 5/20/96 12:00 AM

>>>>> "Dan" == Dan Shiovitz <scy...@u.washington.edu> writes:

> Possibly I'm just obtuse, but it seems to me there's a terribly
> simple solution.  Namely, look at word position.  The first word in
> the line will always be either a verb, or if it's immediately
> followed by a comma, then it's a noun, in which case the comma will
> be followed by a verb. [cut] So what am I missing?

I don't think even the restrictive grammar that adventure games is
quite as restrictive as this.  Somebody else suggested a possible
solution: have the dictionary return a set of possible categories for
the word, and then do an exhaustive search of all ways in which the
sentence might be parsed.  Obviously, this can be made fairly
efficient once you know what grammar you're allowing.  I seem to
remember that Magnetic Scrolls' parsers worked something like this,
but I may be misremembering.  Suitable algorithms appear in Terry
Winograd's "Language as a Cognitive Process, volume 1: Syntax" (hence
the in-joke in one of MS's games about volume 2, which was never
finished).
--
Bruce Stephens                        | email: B.Ste...@math.ruu.nl
Utrecht University              | telephone: +31 30 2534630
Department of Mathematics       | telefax:   +31 30 2518394
P.O. Box 80010, 3508 TA Utrecht |
The Netherlands                 |

Inform in other languages George E Caswell 5/20/96 12:00 AM

On Sun, 19 May 1996, NEIL SLATER wrote:

> Well, I hope I haven't bored you all too much with programming,
>
   ...Not at all...  IMHO if there's a future to parsing in adventure
games, it's a better parser...

    T   I   M   B   U   K   T   U
  ________________ _/>_ _______
 <___ ___________// __/<___   /
    // <> _____  <_  > / ____/
   // /> /    / __/ / / <___________
  // </ </</</ <_ _/ <_____________/
 </             </


Inform in other languages, part 2 George E Caswell 5/20/96 12:00 AM

On Sun, 19 May 1996, John Wood wrote:

> In article: <8C0E29E.0512...@almac.co.uk>  neil....@almac.co.uk (NEIL SLATER)
> writes:
> > If I were to design a parser nowadays (which I could well be doing), I
> > would write an algorithm something like this:
> >
> > 1. Identify all words in the sentence from a dictionary. The dictionary
> > also assigns them a _type_ eg Article, Noun, Verb, Preposition. (This is
> > already failing as a natural language interpreter, but should be adequate
> > for an adventure)
> >
> > eg "use the key to unl the red doo" becomes
> >    "use" "the" "key" "to" "unlock" "the" "red" "door", stored in an array.
> > and  ^V    ^R     ^N  ^P       ^V     ^R   ^A     ^N for types in an
> > array. (R stands for "aRticle")
>
> This stage is actually more of a problem than you might think,
> because many words cannot be unambiguously identified in this way.
>
Couldn't a parser be set up to identify the set of parts of speech a word
might occupy, then try to form gramatical constructs of the possible
permutations to boil down the sentence to a form the parser can deal
with...?  Like where you said lock might be used to identify a padlock or
the verb lock...  the early stages of the parser would be expected to keep
track of lock being either a noun or a verb, then try to figure it out as
it starts breaking prepositional phrases, etc. into simpler forms...?

> Obviously, you wouldn't let things get this far, but if you don't look
> at the structure before identifying the parts you are going to run into
> these sorts of problems.
>
   Perhaps...  's a good point, that maybe the whole concept isn't
completely ready for prime time...  but it's on the right track, I
think...

    T   I   M   B   U   K   T   U
  ________________ _/>_ _______
 <___ ___________// __/<___   /
    // <> _____  <_  > / ____/
   // /> /    / __/ / / <___________
  // </ </</</ <_ _/ <_____________/
 </             </


Parser construction (was: Inform in other languages) Magnus Olsson 5/20/96 12:00 AM

In article <8C0E29E.0512...@almac.co.uk>,

NEIL SLATER <neil....@almac.co.uk> wrote:
>Kees wrote:
>
>KW> Maybe there is a way to evaluate input sentences not in the way Inform
>KW> does, which basically is in a linear way starting with the first word
>KW> cutting down a tree of choices, and then taking the second word.
>KW> Actually, I don't think it can be done in another way. Who knows?
>
>There are probably lots of ways do parse input. There may be some experts
>on this lurking in comp.ai.games, it might be worth a try.
>
>If I were to design a parser nowadays (which I could well be doing), I
>would write an algorithm something like this:


Before everybody starts reinventing the wheel (that is, the parser),
I'd like to point out that parser construction, especially for computer
languages but also for natural languages, is an *extremely* well-researched
problem.

There exists a huge literature about parser construction that
addresses the problems you raise here. There are also tons of tools,
such as yacc, to simplify writing parsers.

So, before you invest a lot of energy in reinventing the wheel, and
above all, before you start posting half-baked ideas about how a
parser should work, *please* check out the existing literature. Or
ask on the AI or compilers newsgroups.

I can just give one reference right now, but it's a good one:

Aho, Sethi and Ullman, Compilers: Principles, Techniques and Tools
(Addison-Wesley 1986)

--
Magnus Olsson (m...@df.lth.se)

Inform in other languages Andrew C. Plotkin 5/20/96 12:00 AM

neil....@almac.co.uk (NEIL SLATER) writes:
> There are probably lots of ways do parse input. There may be some experts
> on this lurking in comp.ai.games, it might be worth a try.
>
> If I were to design a parser nowadays (which I could well be doing), I
> would write an algorithm something like this:
>
> 1. Identify all words in the sentence from a dictionary. The dictionary
> also assigns them a _type_ eg Article, Noun, Verb, Preposition. (This is
> already failing as a natural language interpreter, but should be adequate
> for an adventure)
>
> eg "use the key to unl the red doo" becomes
>    "use" "the" "key" "to" "unlock" "the" "red" "door", stored in an array.
> and  ^V    ^R     ^N  ^P       ^V     ^R   ^A     ^N for types in an
> array. (R stands for "aRticle")
>
> 2. Assign all Adjectives to the respective Nouns to make "Things" (I don't
> want to use the word "Object", my sense of grammer is already bad :-).
> Collapse the sentence, so that there are no Nouns or Adjectives. (You can
> use this to search your game database later.)
>
> eg the example becomes

>    "use" "the" "key" "to" "unlock" "the" "red door", stored in an array.
>      ^V    ^R    ^T   ^P       ^V    ^R         ^T

This is already weaker than the Inform parser, in both stages. For
example, consider "Show audience show". (Which is a perfectly
legitimate command in a game I'm working on. :-) "Show" is both a noun
and a verb, and the two objects are adjacent in the sentence with no
intervening preposition. Inform handles this correctly, since it
assumes that the verb is first, and it has an algorithm to divide up
noun-words into meaningful objects (based on what's actually in the
room.)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

Parser construction (was: Inform in other languages) Bruce Stephens 5/20/96 12:00 AM

>>>>> "Magnus" == Magnus Olsson <m...@marvin.df.lth.se> writes:

> There exists a huge literature about parser construction that
> addresses the problems you raise here. There are also tons of tools,
> such as yacc, to simplify writing parsers.

I don't want to disagree too much, but YACC and similar tools really
are designed for computer languages, not languages where words can fit
into a number of different categories.  What you really want is a
YACC-like system where the lexer gets passed the word category that
YACC is looking for, so it can see whether or not it can satisfy it:
i.e., the direction should go down as well as up.  YACC won't do this.

On the other hand, I'm sure there are systems around which will, even
outside IF companies.


--
Bruce Stephens                        | email: B.Ste...@math.ruu.nl
Utrecht University              | telephone: +31 30 2534630
Department of Mathematics       | telefax:   +31 30 2518394
P.O. Box 80010, 3508 TA Utrecht |
The Netherlands                 |

Parser construction (was: Inform in other languages) Matthew T. Russotto 5/20/96 12:00 AM

In article <4nptbu$5...@news.lth.se>,
Magnus Olsson <m...@marvin.df.lth.se> wrote:

}Before everybody starts reinventing the wheel (that is, the parser),
}I'd like to point out that parser construction, especially for computer
}languages but also for natural languages, is an *extremely* well-researched
}problem.

[..]

}So, before you invest a lot of energy in reinventing the wheel, and
}above all, before you start posting half-baked ideas about how a
}parser should work, *please* check out the existing literature. Or
}ask on the AI or compilers newsgroups.

Or don't.  What have all those AI guys managed to get accomplished?
Nothing.  On the other hand, adventure game parsers written without
the benefit of all that research exist and have worked pretty damn
well.  Why not re-invent the wheel when coming up with a new parser--
perhaps leaving all the AI/natural language parsing theory behind will
allow a working wheel to be constructed.
--
Matthew T. Russotto      russ...@pond.com     russ...@his.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."

Parser construction (was: Inform in other languages) Gareth Rees 5/20/96 12:00 AM

Matthew T. Russotto <russ...@wanda.phl.pond.com> wrote:
> What have all those AI guys managed to get accomplished?  Nothing.

No doubt this is just flame bait, but you're being offensive as well as
ignorant.

SHRDLU was written by Terry Winograd in 1972, and its interface appears
in some ways very much like modern adventure games (though its
implementation is very different).  Here's the kind of thing it can do:
(reprinted in "Godel, Escher, Bach" by Douglas Hofstadter):

  USER: find a block which is taller than the one you are holding and
  put it in the box.

  SHRDLU: By `it', I assume that you mean the block which is taller than
  the one I am holding.  OK.

  USER: how many blocks are not in the box?

  SHRDLU: Four of them.

  USER: is at least one of them narrower than the one which i told you
  to pick up?

  SHRDLU: Yes, the red cube.

This kind of complexity is handled in a general way, rather than by a
collection of special cases.  What modern text adventure can even
attempt to do this kind of thing?  (Note: I am not saying that it
*should* be done).

Other well-known AI programs that do a lot better than adventure games
are Lunar, Sam, Pam, Margie and Lifer.  AI parsing techniques are widely
used in expert systems.

--
Gareth Rees

Parser construction (was: Inform in other languages) Jorn Barger 5/20/96 12:00 AM

In article <yxsloin...@stint.cl.cam.ac.uk>,

Gareth Rees <gd...@cl.cam.ac.uk> wrote:
>Matthew T. Russotto <russ...@wanda.phl.pond.com> wrote:
>> What have all those AI guys managed to get accomplished?  Nothing.
>
>No doubt this is just flame bait, but you're being offensive as well as
>ignorant.

Oh, come on.  'Nothing' is overstated, but it's not *that* overstated...

>SHRDLU was written by Terry Winograd in 1972, and its interface appears
>in some ways very much like modern adventure games (though its
>implementation is very different).  Here's the kind of thing it can do:
>(reprinted in "Godel, Escher, Bach" by Douglas Hofstadter):
[...]

>This kind of complexity is handled in a general way, rather than by a
>collection of special cases. [...]

I had understood the opposite.  I read that Winograd himself admitted
he didn't know how SHRDLU worked.  If it were generalized, we surely
would have seen a lot more of it...?

>Other well-known AI programs that do a lot better than adventure games
>are Lunar, Sam, Pam, Margie and Lifer.

I never heard about Lifer or Lunar, but the middle three are from Yale,
and would have involved exhaustive inventories of special cases, and
applied only to narrow domains...

>  AI parsing techniques are widely used in expert systems.

Well I'd love to see a list of important query-forms that these can
handle.  I'm sure they've gotten a certain way towards NLP, but the
big breakthru is still a long way off.  The mounting evidence against
Cyc seems to confirm this.

j

-==---
... i loved you, so i drew these tides of men into my hands...  _+m"m+_"+_
             lynx http://www.mcs.net/~jorn/ !             Jp   Jp     qh qh
          best-of news:alt.music.category-freak !         O    O       O  O
           ftp://ftp.mcs.com/mcsnet.users/jorn/           Yb   Yb     dY dY
...and wrote my will across the sky in stars.  --R.Graves  "Y_  "Y5m2Y"  "


Inform in other languages, part 2 George E Caswell 5/20/96 12:00 AM

On 20 May 1996, Dan Shiovitz wrote:

> Possibly I'm just obtuse, but it seems to me there's a terribly simple
> solution.  Namely, look at word position.  The first word in the line will
> always be either a verb, or if it's immediately followed by a comma, then it's
> a noun, in which case the comma will be followed by a verb.  You maintain
> lists of verbs, nouns, adjectives, etc, and each time you come to a word whose
> position makes it out to be an X, then you look it up in the appropriate list.

   I don't think that's being terribly obtuse, the solution will work,
probably, (I imagin it would...) The thing is, that' how you create the
same parser that's been used in text adventures since the late 70s, the
strictly command-oriented interface that makes things like "Ford, what
about my home?" nearly impossible to code as anything but a special case.
(Well, it could be analogous to "ford, help me save my home", but the
example really isn't a ford, do this, it's a ford, I am concerned aboutt
this...)  So the solution is fine for making Infocom-esque adventures...
but IMHO efforts should be put toward improving the parser technology we
use...  For example, one thing I'd like to try is...

>Look at the ball.

The ball is a green and red inflatible ball.

>Is the ball inflated?

Yes, it is.

#Maybe even a conditional...

>If the ball is green, kick it.

#or even an attempt at english coding of iterations...

>while the ball is inflated, squeeze it.

>pump up the ball until it is full.

>wait until hell freezes over.

> more than five minutes into it.  So what am I missing?
>
IMHO, progress.

    T   I   M   B   U   K   T   U
  ________________ _/>_ _______
 <___ ___________// __/<___   /
    // <> _____  <_  > / ____/
   // /> /    / __/ / / <___________
  // </ </</</ <_ _/ <_____________/
 </             </


Inform in other languages, part 2 Andrew C. Plotkin 5/21/96 12:00 AM

George E Caswell <timb...@wpi.edu> writes:
>  So the solution is fine for making Infocom-esque adventures...
> but IMHO efforts should be put toward improving the parser technology we
> use...  For example, one thing I'd like to try is...
>
> >Look at the ball.
>
> The ball is a green and red inflatible ball.
>
> >Is the ball inflated?
>
> Yes, it is.
>
> #Maybe even a conditional...
>
> >If the ball is green, kick it.
>
> #or even an attempt at english coding of iterations...
>
> >while the ball is inflated, squeeze it.
>
> >pump up the ball until it is full.
>
> >wait until hell freezes over.
>
> > more than five minutes into it.  So what am I missing?
> >
> IMHO, progress.

Towards what goal? I would enjoy fooling around with such a program
(for that matter, I'd enjoy fooling around with the Winograd program
that people have mentioned) but it isn't a tool for the kind of game I
want to write.

Mmm, except for conversations with NPCs. Ford, what *about* my home?

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

Inform in other languages, part 2 PAZ SALGADO 5/21/96 12:00 AM

George E Caswell (timb...@wpi.edu) wrote:
: So the solution is fine for making Infocom-esque adventures...
: but IMHO efforts should be put toward improving the parser technology we
: use...  For example, one thing I'd like to try is...

: >Look at the ball.

: The ball is a green and red inflatible ball.

: >Is the ball inflated?

: Yes, it is.

: #Maybe even a conditional...

: >If the ball is green, kick it.

: #or even an attempt at english coding of iterations...

: >while the ball is inflated, squeeze it.

: >pump up the ball until it is full.

: >wait until hell freezes over.

I'm completaly agree with this.


        Meliton Rodriguez, from 117 room


Parser construction (was: Inform in other languages) PAZ SALGADO 5/21/96 12:00 AM

Magnus Olsson (m...@marvin.df.lth.se) wrote:
: There exists a huge literature about parser construction that

: addresses the problems you raise here. There are also tons of tools,
: such as yacc, to simplify writing parsers.

Wow! I expect that *yacc* (The Darkness) wouldn't be a real example of a
very well studied parser-maker tool.

Please, yacc is perfect for computer language, but not useful at all for
natural language. If you want to have a good parser forget the computer
parser studies and take your old grammar books!

The general syntax tools I know were created in order to make compilers,
interpreters and so. There is a lot of studies on natural language on AI
but please, put away the studies on computer language parser.

Anyway, the most of development on AI (that try to guess *meaning*)
are too much for us. We don't need *meaning*, and we cannot support a very
big AI of understood machine and our poor computers.

I'm not so sure that talking about parsing we're reinventing the *wheel*
perhaps we can talk about the studies and try to cut away all we don't need.


        Meliton Rodriguez, from 117 room


Parser construction (was: Inform in other languages) L.J. Wischik 5/21/96 12:00 AM

[AI and researchers vs. interactive fiction]

A quick poll of a handful of lecturers and supervisors for the Natural
Language Processing course and the M.Phil. in Computational Linguistics
here had the following result:

Of the four people questioned, not one had even _heard_ of text adventures.
(But one said that he was interested in the commercial applications of
controlling virtual reality by spoken word, which would be kind of the same).

Is anyone aware of any academic papers or tech. reports approaching
natural-language-processing from an interactive fiction sort of
perspective?

--
Lucian Wischik, Queens' College, U of Cambridge. ljw...@cam.ac.uk

Parser construction (was: Inform in other languages) Magnus Olsson 5/21/96 12:00 AM

In article <4nqbdk$h...@wanda.phl.pond.com>,

Matthew T. Russotto <russ...@wanda.phl.pond.com> wrote:
>In article <4nptbu$5...@news.lth.se>,
>Magnus Olsson <m...@marvin.df.lth.se> wrote:
>
>}Before everybody starts reinventing the wheel (that is, the parser),
>}I'd like to point out that parser construction, especially for computer
>}languages but also for natural languages, is an *extremely* well-researched
>}problem.
>
>[..]
>
>}So, before you invest a lot of energy in reinventing the wheel, and
>}above all, before you start posting half-baked ideas about how a
>}parser should work, *please* check out the existing literature. Or
>}ask on the AI or compilers newsgroups.
>
>Or don't.  What have all those AI guys managed to get accomplished?
>Nothing.  

That's only sort of true.

The AI guys have accomplished little in terms of actually *understanding*
natural language. But I don't think the problem is with their parsers,
but on a higher level.

On the other hand, a piece of IF doesn't need very advanced
understanding of the user's commands, as long as we're not talking
about intelligent NPC conversation - _that_ would require more than
the AI people have accomplished so far, granted.

>On the other hand, adventure game parsers written without
>the benefit of all that research exist and have worked pretty damn
>well.

Yes, of course.

>  Why not re-invent the wheel when coming up with a new parser--
>perhaps leaving all the AI/natural language parsing theory behind will
>allow a working wheel to be constructed.

Why not? Well, why do you write your games in TADS or Inform rather
than designing your own IF writing system from scratch? Come to think
of it, why do you use a ready-built computer instead of building one
yourself from spare parts? Or why use spare parts? Why not make your
own transistors from silicon?

But there's of course nothing wrong with designing parsers. In fact,
it can be quite fun.

So, if you like designing new parsers, and are prepared to invest a
lot of time in it, by all means do. All I'm really saying is that you
should check up the literature first.

--
Magnus Olsson (m...@df.lth.se)

Parser construction (and an apology) Magnus Olsson 5/21/96 12:00 AM

In article <4nptbu$5...@news.lth.se>,
Magnus Olsson <m...@marvin.df.lth.se> wrote:
>There exists a huge literature about parser construction that
>addresses the problems you raise here. There are also tons of tools,
>such as yacc, to simplify writing parsers.

It's been pointed out that yacc is not a very good tool for writing
adventure parsers, and of course I was aware of that. I was just using
it as an example of parser-writing tools, but I would *not* recommend
it for writing parsers for natural languages.

>So, before you invest a lot of energy in reinventing the wheel, and
>above all, before you start posting half-baked ideas about how a
>parser should work, *please* check out the existing literature. Or
>ask on the AI or compilers newsgroups.

I'd like to apologize for my remark about "half-baked ideas" - that was
uncalled for and rather abrasive, I'm afraid.

However, my main point remains: anybody interested in writing parsers
should check out the literature *before* trying to invent new, smarter
ways of doing it, just as anyone interested in inventing a cure for
the flu would be wise to check out existing research on viruses before
starting. :-)

--
Magnus Olsson (m...@df.lth.se)

Parser construction (was: Inform in other languages) Bruce Stephens 5/21/96 12:00 AM

>>>>> "Magnus" == Magnus Olsson <m...@marvin.df.lth.se> writes:

> So, if you like designing new parsers, and are prepared to invest a
> lot of time in it, by all means do. All I'm really saying is that
> you should check up the literature first.

I'd agree.  I don't see anything intrinsicly problematic in building a
new parser for Inform, except that Graham has done such a good job
already.  I think it would be quite nice to have a well constructed
tool for producing parsers for Inform, just as it would be nice if
Inform itself used a standard tool like yacc or bison in its
implementation.  For the former, I'd recommend Winograd's "Language as
a Cognitive Process volume 1", if your library has it or can get it;
it has a good selection of easy to understand algorithms, and it's
just about parsing so there's no AI junk in there.


--
Bruce Stephens                        | email: B.Ste...@math.ruu.nl
Utrecht University              | telephone: +31 30 2534630
Department of Mathematics       | telefax:   +31 30 2518394
P.O. Box 80010, 3508 TA Utrecht |
The Netherlands                 |

Parser construction (was: Inform in other languages) Bruce Stephens 5/21/96 12:00 AM

>>>>> "Gareth" == Gareth Rees <gd...@cl.cam.ac.uk> writes:

> SHRDLU was written by Terry Winograd in 1972, and its interface
> appears in some ways very much like modern adventure games (though
> its implementation is very different).  Here's the kind of thing it
> can do: (reprinted in "Godel, Escher, Bach" by Douglas Hofstadter):

[dialog deleted]

> This kind of complexity is handled in a general way, rather than by
> a collection of special cases.  What modern text adventure can even

> attempt to do this kind of thing?  (Note: I am not saying that it
> *should* be done).

I'm sure some could.  I think Infocom's systems were a bit ad-hoc, but
Magnetic Scrolls system (fred) wasn't: it was based on an algorithm,
the name of which I forget, similar to one in Winograd's later book
"Language as a Cognitive Process, vol.1".  The people who built it
were certainly well aware of at least some of the AI work in the
field, as I'm sure those at Infocom and Level-9 were.

Now, I don't think any of their games could cope with what SHRDLU
could, but that's more to do with the domain (some grammatical
constructs weren't needed for the games) and the implementation
restrictions of the machines that on the limitations of the software.

I think it would be very interesting to see what could be done along
the lines of an automatic parser tool for Inform, say, using a
similarly general algorithm.  It might well be much too slow, or
produce parsers much too big, but it would be interesting to see.

Perhaps that would inspire extensions to the Z machine to implement
more general parsers?

There's lots of solid work that could be done; ideal for a final year
undergraduate project, I'd have thought...


--
Bruce Stephens                        | email: B.Ste...@math.ruu.nl
Utrecht University              | telephone: +31 30 2534630
Department of Mathematics       | telefax:   +31 30 2518394
P.O. Box 80010, 3508 TA Utrecht |
The Netherlands                 |

Parser construction (was: Inform in other languages) Bruce Stephens 5/21/96 12:00 AM

>>>>> "Jorn" == Jorn Barger <jo...@MCS.COM> writes:

> Well I'd love to see a list of important query-forms that these can
> handle.  I'm sure they've gotten a certain way towards NLP, but the
> big breakthru is still a long way off.  The mounting evidence
> against Cyc seems to confirm this.

I'm sure Gareth's point is that there are systems which do better than
current interactive fiction games, not that real NLP is possible right
now.

An interactive fiction game has a nice restricted domain (it'll have
humans, typically, but we know we can't implement them all that well,
so it doesn't matter that much if the parser doesn't cope with asking
them which football team they support).  It's surely a good domain for
applying ten year old AI research into parsing?

Why can't I ask a game "How many keys are on the table?" and have it
reply "Four (including two in the box and one that you can see inside
a glass sphere)."?  And why shouldn't an interactive fiction writing
system provide this kind of generality automatically, and safely?


--
Bruce Stephens                        | email: B.Ste...@math.ruu.nl
Utrecht University              | telephone: +31 30 2534630
Department of Mathematics       | telefax:   +31 30 2518394
P.O. Box 80010, 3508 TA Utrecht |
The Netherlands                 |

Parser construction (was: Inform in other languages) Julian Arnold 5/21/96 12:00 AM

In article <4nrs7c$7...@news.lth.se>, Magnus Olsson

<mailto:m...@marvin.df.lth.se> wrote:
>
> >  Why not re-invent the wheel when coming up with a new parser--
> >perhaps leaving all the AI/natural language parsing theory behind will
> >allow a working wheel to be constructed.
>
> Why not? Well, why do you write your games in TADS or Inform rather
> than designing your own IF writing system from scratch? Come to think
> of it, why do you use a ready-built computer instead of building one
> yourself from spare parts? Or why use spare parts? Why not make your
> own transistors from silicon?
>
> But there's of course nothing wrong with designing parsers. In fact,
> it can be quite fun.
>
> So, if you like designing new parsers, and are prepared to invest a
> lot of time in it, by all means do. All I'm really saying is that you
> should check up the literature first.

Yes, this phrase "don't re-invent the wheel" is a bit overused in this group,
and isn't necessarily the best advice.  For instance, Kent Tessmann's
re-invention of the wheel (resulting in Hugo) was extremely worthwhile, as
was Dave Baggett's re-invention of the wheel (WorldClass), to name but two.

I think what people mean to say, as Magnus has also explained above, is be
aware that we have wheels, and they go round, albeit a bit bumpily in places.
Knowing this, if you still want to create your own wheel, or think you can
make a better, rounder one, go ahead.

-- Jools


Parser construction (was: Inform in other languages) Andrew C. Plotkin 5/21/96 12:00 AM

step...@math.ruu.nl (unknown) writes:
> I think it would be very interesting to see what could be done along
> the lines of an automatic parser tool for Inform, say, using a
> similarly general algorithm.  It might well be much too slow, or
> produce parsers much too big, but it would be interesting to see.

Yes.

> Perhaps that would inspire extensions to the Z machine to implement
> more general parsers?

Er, what could be more general than the one that's in there now?
(Namely, (optionally) split the input into words and then run the
program.)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

Parser construction (was: Inform in other languages) unknown 5/21/96 12:00 AM

>>>>> "Andrew" == Andrew C Plotkin <erky...@CMU.EDU> writes:

> step...@math.ruu.nl (unknown) writes:

>> Perhaps that would inspire extensions to the Z machine to implement
>> more general parsers?

> Er, what could be more general than the one that's in there now?
> (Namely, (optionally) split the input into words and then run the
> program.)

Sorry, I meant "at a reasonable speed/memory cost".  One could easily
imagine adding opcodes to do appropriate things (find this word in the
dictionary, or just "is this word a _", where _ is noun, adjective or
whatever) if it turned out that Z-code was too slow to be comfortable,
or just required such a large amount of code that new opcodes seemed
logical.

I'm really just urging people not to write yet another system where
working within an existing one (even, at the end of the day, extending
it) looks at least plausible.
--
Bruce Stephens                        | email: B.Ste...@math.ruu.nl
Utrecht University              | telephone: +31 30 2534630
Department of Mathematics       | telefax:   +31 30 2518394
P.O. Box 80010, 3508 TA Utrecht |
The Netherlands                 |

Parser construction (was: Inform in other languages) Magnus Olsson 5/21/96 12:00 AM

In article <4nrsp6$3...@tid.tid.es>, PAZ SALGADO <ja...@tid.tid.es> wrote:
>Magnus Olsson (m...@marvin.df.lth.se) wrote:
>: There exists a huge literature about parser construction that
>: addresses the problems you raise here. There are also tons of tools,
>: such as yacc, to simplify writing parsers.
>
>Wow! I expect that *yacc* (The Darkness) wouldn't be a real example of a
>very well studied parser-maker tool.
>
>Please, yacc is perfect for computer language, but not useful at all for
>natural language.

Many people think it's far from perfect even for computer languages :-).
(Actually, I was using yacc only as an example of a parser writing tool.
I didn't mean that it was good for natural language parsers).

> If you want to have a good parser forget the computer
>parser studies and take your old grammar books!

Huh? The old grammar books tell you nothing about parsers. You could do
well with some *new* grammar books, namely those dealing with generative
(Chomsky) grammars.

Let me expand a little. Generative grammar can be seen as an attempt
to write down rules for how to construct correct sentences in a language
(computer or natural). However, the rules are also useful the other way
round, in parsing sentences, i.e. trying to find out the functions of
each word.

The grammar part of an Inform program consists of a number of generative
grammar rules. You could in principle write a program that takes the
Inform source code and uses the grammar to generate all possible input
sentences that the game will recognize; that's the generative part. :-)

>The general syntax tools I know were created in order to make compilers,
>interpreters and so. There is a lot of studies on natural language on AI
>but please, put away the studies on computer language parser.

I think it's not quite as bad as that. Computer languages are generally
much simpler than natural language, and parser writers utilize this
knowledge to optimize their algorithms. This is one of the reasons why
yacc is bad for naturla language.

However, the _general_ theory of parsing is the same for all languages
and it is presented quite well in compiler textbooks.

BTW, we've mentioned compiler people and AI people as experts on
parsing.  Let's not forget that there are many people doing research
in computerized linguistics (for example, there's a well-known
research group in the linguistics department at Lund U. who're working
on computer-based translation). The research of these people is
perhaps more applicable to adventure parsers?

--
Magnus Olsson (m...@df.lth.se)

Parser construction (was: Inform in other languages) Gareth Rees 5/22/96 12:00 AM

L.J. Wischik <ljw...@thor.cam.ac.uk> wrote:
> Is anyone aware of any academic papers or tech. reports approaching
> natural-language-processing from an interactive fiction sort of
> perspective?

I think the Oz project at Carnegie-Mellon university is about the extent
of it.  See <URL:http://www.cs.cmu.edu/afs/cs.cmu.edu/project/oz/>.

--
Gareth Rees

Parser construction (was: Inform in other languages) PAZ SALGADO 5/22/96 12:00 AM

Magnus Olsson (m...@marvin.df.lth.se) wrote:
: > If you want to have a good parser forget the computer

: >parser studies and take your old grammar books!

: Huh? The old grammar books tell you nothing about parsers. You could do
: well with some *new* grammar books, namely those dealing with generative
: (Chomsky) grammars.

  Well, my old grammar book talks about Chomsky, perhaps I'm too young.

  Anyway, there is lots of difference between natural and computer
language, because the computer language HAS CLEAR RULES, and ALL you
can write with these rules are correct (at least on syntax). But the
natural language have no clear rules. For reach correct phrase you
need meaning, and for parsing you need some kind of heuristic decision
very different of actions needed to parse computer language. But the worst
it is that these decision change a lot between one natural language and
another (I'm thinking about Japanesse, for instance).

: Let me expand a little. Generative grammar can be seen as an attempt


: to write down rules for how to construct correct sentences in a language
: (computer or natural). However, the rules are also useful the other way
: round, in parsing sentences, i.e. trying to find out the functions of
: each word.

These ideas was written on my old grammar book (spanish grammar book).

: BTW, we've mentioned compiler people and AI people as experts on


: parsing.  Let's not forget that there are many people doing research
: in computerized linguistics (for example, there's a well-known
: research group in the linguistics department at Lund U. who're working
: on computer-based translation). The research of these people is
: perhaps more applicable to adventure parsers?

Of couse! But usually the have a very big computer and lots of time, I
think....


        Meliton Rodriguez, from 117 room

Parser construction (was: Inform in other languages) Den of Iniquity 5/22/96 12:00 AM

On 21 May 1996, Bruce Stephens wrote:

> Why can't I ask a game "How many keys are on the table?" and have it
> reply "Four (including two in the box and one that you can see inside
> a glass sphere)."?  And why shouldn't an interactive fiction writing
> system provide this kind of generality automatically, and safely?

Oh it would be a nice touch, and I'll not say that the inclusion of this
kind of complexity in a game is a bad idea; it isn't. But... We're
talking about writing games here, not machines that could pass the Turing
test. Once voice recognition becomes a more ordinary way to interact with
your computer then this could be a desirable feature but for the time
being, what we need is a way to tell the computer what we want to do
*concisely* - and that, I think is the key.

If a game had such a parser that it could understand and give a meaningful
answer to "How many keys are there on the table?" I would be impressed,
and no doubt I'd have a go at typing a few such commands in to gaze in awe
at the clever responses. But before long I'd swiftly revert back to
this:

> l

 You are in a spacious room with a large table. On the table is a box
which looks like it contains two silver keys, an iron key in a glass globe
and a large ornate key.


and then I'd count the keys myself. I don't think I have much use for fancy
parser footwork. I know this is perhaps not the best example but I can't
think of any other areas in i-f where this kind of complexity would
supercede existing parser except perhaps in the area of interaction with
NPCs.

However... If someone created a virtual world in a computer with physical
laws of space and forces obeyed, allowed the player to manipulate
virtually everything and then wrote a clever 'describe' routine to
describe exactly what the player saw (rather than using a single or a
small set of stock responses) then this kind of parser would come into its
own. At the pantry_location with the Power-sausage-peeler (gives attack +3
when fighting sausages) hidden in a cupboard_drawer with other
non-takeable class_utensils, instead of being told (of a soup can, say)
"Leave that alone. That's not important." you could use these new-found
parser powers to carefully stack a large selection of soup cans to hamper
a hero's progress.

I believe that's a fair way off being implemented yet. But there's no
harm in exploring the avenues towards it - it gives you a head start on
everyone else ;)

--
Den

Inform in other languages, part 2 George E Caswell 5/22/96 12:00 AM

On Tue, 21 May 1996, Andrew C. Plotkin wrote:

> > >
> > IMHO, progress.
>
> Towards what goal? I would enjoy fooling around with such a program
> (for that matter, I'd enjoy fooling around with the Winograd program
> that people have mentioned) but it isn't a tool for the kind of game I
> want to write.
>
   Well, a few reasons I guess.  First, it seems to me as though the
current I-F games being made are very similar technologically to those
made 15 years ago.  Esp. Inform.  IMHO effort should be put to revamping
our ideas of how IF works and how we interact with it.  Infocoms, in some
cases, used every iota of resource available on the meager home system
available then.  It's not too worthwhile pushing your average 486 system
to the extremes for a text adventure...  but pushing the envelope of
what's been done is certainly a good thing.  Second, it's progress.
Progress is good, and more often than not, leads to more progress.  

> Mmm, except for conversations with NPCs. Ford, what *about* my home?
>
   I don't know if the system I hypothesized would be able to do that...
but it would be a step.  (again) IMHO we should be moving forward
technologically-  I think we'd all welcome a little more flexibility in
talking to a game...

    T   I   M   B   U   K   T   U
  ________________ _/>_ _______
 <___ ___________// __/<___   /
    // <> _____  <_  > / ____/
   // /> /    / __/ / / <___________
  // </ </</</ <_ _/ <_____________/
 </             </


Inform in other languages, part 2 John Francis 5/22/96 12:00 AM

George E Caswell wrote:
>
> On Sun, 19 May 1996, John Wood wrote:
>
> > In article: <8C0E29E.0512...@almac.co.uk>  neil....@almac.co.uk (NEIL SLATER)
> > writes:
> > > If I were to design a parser nowadays (which I could well be doing), I
> > > would write an algorithm something like this:
> > >
> > > 1. Identify all words in the sentence from a dictionary. The dictionary
> > > also assigns them a _type_ eg Article, Noun, Verb, Preposition. (This is
> > > already failing as a natural language interpreter, but should be adequate
> > > for an adventure)
> > >
> > > eg "use the key to unl the red doo" becomes
> > >    "use" "the" "key" "to" "unlock" "the" "red" "door", stored in an array.
> > > and  ^V    ^R     ^N  ^P       ^V     ^R   ^A     ^N for types in an
> > > array. (R stands for "aRticle")
> >
> > This stage is actually more of a problem than you might think,
> > because many words cannot be unambiguously identified in this way.
> >
> Couldn't a parser be set up to identify the set of parts of speech a word
> might occupy, then try to form gramatical constructs of the possible
> permutations to boil down the sentence to a form the parser can deal
> with...?  Like where you said lock might be used to identify a padlock or
> the verb lock...  the early stages of the parser would be expected to keep
> track of lock being either a noun or a verb, then try to figure it out as
> it starts breaking prepositional phrases, etc. into simpler forms...?

Consider the "classic" problem:

        Time flies like an arrow.
        Fruit flies like a banana.
        Paint flies like an artist.

Parser construction (was: Inform in other languages) Magnus Olsson 5/23/96 12:00 AM

In article <4numum$9...@tid.tid.es>, PAZ SALGADO <ja...@tid.tid.es> wrote:
>Magnus Olsson (m...@marvin.df.lth.se) wrote:
>: > If you want to have a good parser forget the computer
>: >parser studies and take your old grammar books!
>
>: Huh? The old grammar books tell you nothing about parsers. You could do
>: well with some *new* grammar books, namely those dealing with generative
>: (Chomsky) grammars.
>
>  Well, my old grammar book talks about Chomsky, perhaps I'm too young.

Well, Chmosky did his work in the 50's if I'm not mistaken. I think
generative grammar has been moved in and out of grammar textbooks
since then. It's a bit like set theory in maths: it used to be very
advanced and taught in second-year university courses, then it moved
into elementary textbooks, then it moved out again :-).


>  Anyway, there is lots of difference between natural and computer
>language, because the computer language HAS CLEAR RULES, and ALL you
>can write with these rules are correct (at least on syntax). But the
>natural language have no clear rules. For reach correct phrase you
>need meaning, and for parsing you need some kind of heuristic decision
>very different of actions needed to parse computer language. But the worst
>it is that these decision change a lot between one natural language and
>another (I'm thinking about Japanesse, for instance).

True, but I think we're missing an important point here:

The language accepted by an IF parser is not really natural language,
but a simulation. The very fact that the language *is* acceptable
by a parser means that it can be described as a formal language. It is
desirable that this formal language be as similar to natural language
as possible, but all existing IF puts rather stringent restrictions
on how you formulate your commands.


>        Meliton Rodriguez, from 117 room

BTW, how come you're signing your messages "Meliton Rodrgiuez" but the
message headers say "Paz Salgado"?

--
Magnus Olsson (m...@df.lth.se)

Inform in other languages, part 2 John Wood 5/23/96 12:00 AM

George E Caswell <timb...@wpi.edu> writes:
> Couldn't a parser be set up to identify the set of parts of speech a word
> might occupy, then try to form gramatical constructs of the possible
> permutations to boil down the sentence to a form the parser can deal
> with...?  Like where you said lock might be used to identify a padlock or
> the verb lock...  the early stages of the parser would be expected to keep
> track of lock being either a noun or a verb, then try to figure it out as
> it starts breaking prepositional phrases, etc. into simpler forms...?

Possibly, but if you get too many words that can be used in different
parts of speech (such as PLANT being verb, adjective or noun) you'll get
a combinatorial blossoming (slightly less drastic than an explosion, but
still annoying when you have to sweep up the mess 8-).

> > Obviously, you wouldn't let things get this far, but if you don't look
> > at the structure before identifying the parts you are going to run into
> > these sorts of problems.
> >
>    Perhaps...  's a good point, that maybe the whole concept isn't
> completely ready for prime time...  but it's on the right track, I
> think...

I just wonder if it's not simpler in the end to look at the structure
early on - I'm waiting to be convinced that this method has significant
advantages over the Inform structure-based approach.

John


Inform in other languages, part 2 John Wood 5/23/96 12:00 AM

In article: <4nopl1$h...@nntp4.u.washington.edu>  
scy...@u.washington.edu (Dan Shiovitz) writes:
> Possibly I'm just obtuse, but it seems to me there's a terribly simple
> solution.  Namely, look at word position.  The first word in the line will
> always be either a verb, or if it's immediately followed by a comma, then it's
> a noun, in which case the comma will be followed by a verb.  You maintain
> lists of verbs, nouns, adjectives, etc, and each time you come to a word whose
> position makes it out to be an X, then you look it up in the appropriate list.

I was going to respond to this, but I believe Bruce Stephens and George E.
Caswell have said it all for me.

Note that I didn't say the overall scheme wouldn't work - merely that there
were problems "brushed under the carpet" in the initial post which needed
addressing.

By the way, I should mention that I've had no formal computer training (other
than a short introductory LISP course at Uni), and I haven't had to deal with
parsing beyond command-line arguments and expression evaluators, so my
opinions should be regarded as uninformed.

John


Inform in other languages, part 2 L.J. Wischik 5/23/96 12:00 AM

scy...@u.washington.edu (Dan Shiovitz) writes:
> Possibly I'm just obtuse, but it seems to me there's a terribly simple >
> solution.  Namely, look at word position.  The first word in the line will
> always be either a verb, or if it's immediately followed by a comma,
> then it's > a noun, in which case the comma will be followed by a verb.
> You maintain > lists of verbs, nouns, adjectives, etc, and each time you
> come to a word whose > position makes it out to be an X, then you look it
> up in the appropriate list.

Delicately compose a reply.
Without departing from style, make the point that additional clauses can
go at the front.
Politely suggest that there is more than mere word order.
Closing with a final example and a .sig, return to work.

--
Lucian

Parser construction (was: Inform in other languages) Greg Ewing 5/24/96 12:00 AM

Matthew T. Russotto wrote:
>
> In article <4nptbu$5...@news.lth.se>,
> Magnus Olsson <m...@marvin.df.lth.se> wrote:
>
> What have all those AI guys managed to get accomplished?
> Nothing.  

They've been tackling a much wider problem. An IF parser
doesn't need to cope with anything remotely as general
as unrestricted natural language. Techniques which are
only slightly effective with full natural language
may be much more useful in the restricted domain of
IF. Worth looking into, anyhow, surely?

Greg

Parser construction (was: Inform in other languages) Greg Ewing 5/24/96 12:00 AM

Gareth Rees wrote:
> SHRDLU was written by Terry Winograd in 1972, and its interface appears
> in some ways very much like modern adventure games (though its
> implementation is very different).  Here's the kind of thing it can do:
> (reprinted in "Godel, Escher, Bach" by Douglas Hofstadter):

From what I remember of that passage, Hofstadter said
he'd paraphrased the input and output, so we can't really
conclude anything about SHRDLU's natural language
ability from that transcript.

It would be interesting to see
an example of what SHRDLU's input language was really
like.

> Gareth Rees

Greg

Parser construction (was: Inform in other languages) PAZ SALGADO 5/24/96 12:00 AM

Magnus Olsson (m...@marvin.df.lth.se) wrote:
: Well, Chmosky did his work in the 50's if I'm not mistaken. I think

: generative grammar has been moved in and out of grammar textbooks
: since then. It's a bit like set theory in maths: it used to be very
: advanced and taught in second-year university courses, then it moved
: into elementary textbooks, then it moved out again :-).

Ow! Here, in Spain, the textbooks have both, Chomsky and set theory...

: The language accepted by an IF parser is not really natural language,


: but a simulation. The very fact that the language *is* acceptable
: by a parser means that it can be described as a formal language. It is
: desirable that this formal language be as similar to natural language
: as possible, but all existing IF puts rather stringent restrictions
: on how you formulate your commands.

OK, but not for NPCs talking... I love NPCs...


: >        Meliton Rodriguez, from 117 room

: BTW, how come you're signing your messages "Meliton Rodrgiuez" but the
: message headers say "Paz Salgado"?

"Meliton Rodriguez" is my war-name, I don't know who to say "seudonimo" in English.
Here I write some I-Fs related publications, and I allways use this name.

Parser construction (was: Inform in other languages) Bruce Stephens 5/24/96 12:00 AM

>>>>> "Den" == Den of Iniquity <dms...@york.ac.uk> writes:

> On 21 May 1996, Bruce Stephens wrote:

>> Why can't I ask a game "How many keys are on the table?" and have
>> it reply "Four (including two in the box and one that you can see
>> inside a glass sphere)."?  And why shouldn't an interactive fiction
>> writing system provide this kind of generality automatically, and
>> safely?

> Oh it would be a nice touch, and I'll not say that the inclusion of
> this kind of complexity in a game is a bad idea; it
> isn't.

Counting is a bit of a gimic, and if I really wanted to know, I'd type
"how many keys on table".  And, of course, if it were essential to the
plot, you could stick in some ad-hoc stuff to do it.  But perhaps
Gareth Rees has an idea: perhaps now we've got powerful enough
computers, we should be aiming for more bells and whistles as
standard, without requiring special effort on the part of the game
writer?

Inform (with its libraries) has enough information to do counting: if
I can "get keys" (or is it "get all keys"?) then it could presumably
count them too.

The difficult bit, and it's especially difficult with interactive
fiction, is how to get the error messages right.  It's all very well
if I say "plant pot plant in plant pot" and there's a pot plant and a
plant pot handy, but what error message should I get if I don't have
anything appropriate?  

What if I just say "plant pot"?  Should it say something to the effect
that I don't want to plant a pot, or should it ask what I want to do
with the plant pot?  (Both are likely to parse, assuming I have a
plant pot.)  I'm frequently amazed that Inform's libraries get it
right (well, perhaps plausible is a better word) as often as they do.


--
Bruce Stephens                        | email: B.Ste...@math.ruu.nl
Utrecht University              | telephone: +31 30 2534630
Department of Mathematics       | telefax:   +31 30 2518394
P.O. Box 80010, 3508 TA Utrecht |
The Netherlands                 |

Parser construction (was: Inform in other languages) David Librik 5/25/96 12:00 AM

m...@marvin.df.lth.se (Magnus Olsson) writes:

>In article <4numum$9...@tid.tid.es>, PAZ SALGADO <ja...@tid.tid.es> wrote:
>>Magnus Olsson (m...@marvin.df.lth.se) wrote:
>>: > If you want to have a good parser forget the computer
>>: >parser studies and take your old grammar books!
>>
>>: Huh? The old grammar books tell you nothing about parsers. You could do
>>: well with some *new* grammar books, namely those dealing with generative
>>: (Chomsky) grammars.
>>
>>  Well, my old grammar book talks about Chomsky, perhaps I'm too young.

>Well, Chmosky did his work in the 50's if I'm not mistaken. I think
>generative grammar has been moved in and out of grammar textbooks
>since then.

The '60s, really, though Chomsky's original ideas were written up in
the late '50s.  He wrote a short and accessible book called _Syntactic
Structures_ that showed why Transformational Grammar was the way to go,
and his ideas were a big success.  By the late 1960s nobody was really
doing anything else when it came to syntax.

The trouble is that Chomsky's generative grammar (Transformational
Grammar) was shown in the 1970s to be computationally unreasonable.
Computer Scientists showed that it was "equivalent to a Turing Machine
in generative power" (read: really tough to use for parsing), and
Psychologists concluded that it doesn't match up with what we know
about language use.  This sent a lot of people (including Chomsky)
scurrying off to try to simplify the theory, often to make it more
amenable to use with computers.

The first attempt at a computationally reasonable model of grammar
was developed at Stanford and Xerox PARC (the same place that
invented the Mouse and the Graphical User Interface, and then ignored
their inventions until Apple ripped them off).  This was Joan Bresnan's
"Lexical Functional Grammar."  The programmers at PARC were able to
do quite a lot of good natural-language processing with LFG as a tool.

The Linguistics idea that I think would make a good tool for increasing
the power of Adventure parsers is Construction Grammar, developed by
Charles Fillmore (whose Case Grammar was big in natural-language parsing
in the '70s), Paul Kay, and Adele Goldberg.  Their idea is that not
just words have meaning, but constructions -- patterns of how words
appear together -- have their own meanings, independent of the words
that appear inside them.  Goldberg gives these English examples:

        push    the box      out of the room
        kick    the ball     away
        sneeze  the Kleenex  off the table

and claims that the *structure*, the *pattern* that these words fall into,
has its own semantic meaning of "cause directional motion."  Whatever verbs,
nouns, and directional phrases you can shove into this structure, you end up
with something whose meaning is more than just the meaning of the
individual parts -- there's nothing in "sneeze" "the Kleenex" and "off
the table" that implies the sneezing causes the Kleenex to move off the
table.  Also, constructions combine with each other -- each one carrying
its own bits of semantic meaning; as the constructions combine their
forms, so do their meanings combine, until you've built up a whole
sentence.  You can handle this combination by "unification" -- a familiar
technique to anyone who's taken a programming class that dealt with PROLOG
or database management.  Find a combination of constructions that unify
to form the input sentence, and the parallel combination of semantics will
give you the meaning of that sentence.  (For simplicity's sake, individual
words and parts of words are also "constructions," meaning there's only
one data type.)

Now what does this mean for Interactive-fiction parsers?  It's pretty
clear that so far we've only been able to handle a few constructions:
the ones which appear in:

        JUMP
        OPEN BOTTLE
        SHOW THE STILETTO TO THE THIEF

Furthermore, a lot of different constructions have been parsed in
the same way, leaving it up to the verb-processing code to handle
the differences in meaning.  To see what I mean, notice that:

        Magnus kicked the ball behind the barn.
        David stabbed the boy behind the barn.

seem to have exactly the same form, but the second doesn't have
a "caused motion" meaning.  So, more than one construction can result
in the same surface form.  (In fact, I suspect the second sentence
is a combination of two constructions: a "transitive sentence"
construction which just lets you say things like "David stabbed
the boy," and another one which lets you augment a verb phrase with
an adverbial [prepositional phrase or adverb] describing where
something took place.)  In Infocom-like games, this is paralleled
by the fact that:

        GIVE THE VASE TO THE TROLL
   and  CONNECT THE RED PLUG TO THE BLACK SOCKET

are parsed exactly the same, and each verb has to figure out separately
exactly what to do with its arguments.  The "meaning" (i.e. what actions
to perform) is associated purely with the verb -- and in more object-
oriented I-F languages, with the nouns too.  A Construction Grammar
solution would let some of the meaning get handled by routines for
the syntactic constructions used in the sentence, and thus would
(1) make the individual verb/noun coding a lot simpler, (2) handle new
combinations of words better, and (3) let us start adding new constructions
to the language that the parser can understand, and thus finally get beyond
Infocom.

- David Librik
lib...@cs.Berkeley.edu

Inform in other languages, part 2 George E Caswell 5/26/96 12:00 AM

On Wed, 22 May 1996, John Francis wrote:

> George E Caswell wrote:
> >
> > Couldn't a parser be set up to identify the set of parts of speech a word
> > might occupy, then try to form gramatical constructs of the possible
> > permutations to boil down the sentence to a form the parser can deal
> > with...?  Like where you said lock might be used to identify a padlock or
> > the verb lock...  the early stages of the parser would be expected to keep
> > track of lock being either a noun or a verb, then try to figure it out as
> > it starts breaking prepositional phrases, etc. into simpler forms...?
>
> Consider the "classic" problem:
>
>         Time flies like an arrow.

   ...A command which no game I can think of (except, possibly, a
follow-up to Nord n' Bert) would use...

>         Fruit flies like a banana.

   Assuming you had a game AI/Parser advanced enough to handle, store, and
work with user-entered assumptions (something not terribly necessary in
any game I can think of) the parser would need to be able to identify the
noun "Fruit Fly"...  And then, hopefully, it would be intelligent enough
to ask the question,
   "Were you describing how fruit can fly, or were you describing
something a fruit fly might like?"

>         Paint flies like an artist.

   I never really understood that one myself, I wouldn't inflict it on a
poor unsuspecting parser.

   Notes:  While debated, your point is taken.  However, as wild as my
ideas for newer parsers might sound, my goal isn't to have new IF pass the
Turing test-  It's not even, necessarily to revolutionize the IF interface
overnight-  It's to make the parsers move -forward-.  So the technique I
described would work, for the parser in the advancing, but still limited
context of IF.

    T   I   M   B   U   K   T   U
  ________________ _/>_ _______
 <___ ___________// __/<___   /
    // <> _____  <_  > / ____/
   // /> /    / __/ / / <___________
  // </ </</</ <_ _/ <_____________/
 </             </


Parser construction (was: Inform in other languages) George E Caswell 5/26/96 12:00 AM

On 24 May 1996, unknown wrote:

> >>>>> "Den" == Den of Iniquity <dms...@york.ac.uk> writes:
>
> > On 21 May 1996, Bruce Stephens wrote:
>
> >> Why can't I ask a game "How many keys are on the table?" and have
> >> it reply "Four (including two in the box and one that you can see
> >> inside a glass sphere)."?  And why shouldn't an interactive fiction
> >> writing system provide this kind of generality automatically, and
> >> safely?
>
> > Oh it would be a nice touch, and I'll not say that the inclusion of
> > this kind of complexity in a game is a bad idea; it
> > isn't.
>
> Counting is a bit of a gimic, and if I really wanted to know, I'd type
> "how many keys on table".  And, of course, if it were essential to the
> plot, you could stick in some ad-hoc stuff to do it.  But perhaps
> Gareth Rees has an idea: perhaps now we've got powerful enough
> computers, we should be aiming for more bells and whistles as
> standard, without requiring special effort on the part of the game
> writer?
>
> Inform (with its libraries) has enough information to do counting: if
> I can "get keys" (or is it "get all keys"?) then it could presumably
> count them too.
>
Making it do something -useful- with this information is where it gets
more complicated.  (Such things, IMHO, are steps that IF must take, steps
that could fundamentally change how we interact with I-F)

    T   I   M   B   U   K   T   U
  ________________ _/>_ _______
 <___ ___________// __/<___   /
    // <> _____  <_  > / ____/
   // /> /    / __/ / / <___________
  // </ </</</ <_ _/ <_____________/
 </             </


Parser construction (was: Inform in other languages) Kenneth Fair 5/26/96 12:00 AM

In article <4o3q13$d...@tid.tid.es>, ja...@tid.tid.es (PAZ SALGADO) wrote:

>Magnus Olsson (m...@marvin.df.lth.se) wrote:
>: BTW, how come you're signing your messages "Meliton Rodrgiuez" but the
>: message headers say "Paz Salgado"?
>
>"Meliton Rodriguez" is my war-name, I don't know who to say "seudonimo"
in English.
>Here I write some I-Fs related publications, and I allways use this name.

"Pseudonym" is the word you're looking for.

"War-name"?  Hmmm.  That's an interesting way to put it.  Maybe I'm
losing something in translation.

--
KEN FAIR - U. Chicago Law  | <http://student-www.uchicago.edu/users/kjfair>
Of Counsel, U. of Ediacara | Power Mac! | CABAL(tm) | I'm w/in McQ - R U?
   To me, boxing is like a ballet, except there's no music, no
   choreography, and the dancers hit each other.

Parser construction (was: Inform in other languages) Adam J. Thornton 5/26/96 12:00 AM

In article <kjfair-2605...@uchinews.uchicago.edu>,

Kenneth Fair <kjf...@midway.uchicago.edu> wrote:
>"War-name"?  Hmmm.  That's an interesting way to put it.  Maybe I'm
>losing something in translation.

Show me your PROGRAMMING face, Soldier!

Adam
--
ad...@phoenix.princeton.edu | Viva HEGGA! | Save the choad! | 64,928 | Fnord
"Double integral is also the shape of lovers curled asleep":Pynchon | Linux
Thanks for letting me rearrange the chemicals in your head. | Team OS/2
You can have my PGP passphrase when you pry it from my cold, dead brain.

Parser construction (was: Inform in other languages) PAZ SALGADO 5/27/96 12:00 AM

David Librik (lib...@netcom.com) wrote:
: m...@marvin.df.lth.se (Magnus Olsson) writes:
: exactly what to do with its arguments.  The "meaning" (i.e. what actions

: to perform) is associated purely with the verb -- and in more object-
: oriented I-F languages, with the nouns too.  A Construction Grammar
: solution would let some of the meaning get handled by routines for
: the syntactic constructions used in the sentence, and thus would
: (1) make the individual verb/noun coding a lot simpler, (2) handle new
: combinations of words better, and (3) let us start adding new constructions
: to the language that the parser can understand, and thus finally get beyond
: Infocom.

I didn't know any other grammar theory but the Chomsky style when I wrote
my CAECHO?, so I tried to get the different part of phrase with meaning
(in spanish are called "sintagmas"), using the preposition position
adverbs and so. I couldn't analyze complex phrase like:

>> Say to Power Dragon "Oh Please, Make  I Win Lots Of Money"
                        ^          ^     ^
                        Forget     Fisrt Second Phrase

I were not very happy because of this limitation.

But I went very surprised when I understood that Inform have no
"sintagma" parsing at all.

Anyway, I think that english (at least, England english) are more order-
oriented language than spanish in which:

>> "Coge la pelota" (Take the ball)
>> "Coloca la pelota en la caja" (Put the ball in the box)

Are exactaly the same that

>> "Coge la pelota" (Take the ball)
>> "Coloca en la caja la pelota" (Put in the box the ball)
>> "Colocala en la caja" (Put it in the box)

and so...


        Meliton Rodriguez, from 117 room


Parser construction (was: Inform in other languages) Chris Thomas 5/27/96 12:00 AM

In article <librikDr...@netcom.com>, lib...@netcom.com (David Librik)
wrote:

*** off topic **

> The first attempt at a computationally reasonable model of grammar
> was developed at Stanford and Xerox PARC (the same place that
> invented the Mouse and the Graphical User Interface, and then ignored
> their inventions until Apple ripped them off).

I have to correct the historical inaccuracies in the above.  Xerox
PARC did not invent the mouse or the Graphical User Interface.
Xerox PARC refined them to a certain rough level, *then* ignored
them, and Apple later refined them into a Human Interface.

*** end off topic ***

--
Chris Thomas, c...@best.com $200 per-message fine for usenet grepspam
sent to this address

Parser construction (was: Inform in other languages) Greg Ewing 5/28/96 12:00 AM

PAZ SALGADO wrote:
> But I went very surprised when I understood that Inform have no
> "sintagma" parsing at all.

Parsing a traditional IF-style command language doesn't
necessarily require dividing words into the usual categories
of nouns, adjectives, verbs, prepositions, etc. You can
get a long way by just having a bunch of patterns to
match against, e.g.

        take (x)
        put (x) into (y)
        give (x) to (y)
        kick (x)
        kick (x) behind (y)
        
Then given a command like

        put large squeegee into filthy mop bucket

it clearly matches the 2nd template above thus:

        put (large squeegee) into (filthy mop bucket)

So you then go looking for objects whose names include
the word sets {large, squeegee} and {filthy, mop, bucket}.

The point is that it doesn't matter that "put" is a verb
and "into" is a preposition, or that "large" is an adjective
and "squeegee" a noun.

Of course, this system does have a problem with things like

        give housemaid squeegee

To deal with that you need some way of splitting up two
concatenated sequences of nouns/adjectives. You could
distinguish between nouns and adjectives, but that can
lead to difficulties with words like "pot" which can be
either. You could recognise articles, but they really
ought to be optional, and they can't be used with some
nouns anyway.

A better way might be to use the contents of the world
to help parse the sentence. E.g. if there is no single
object present whose name includes both "housemaid"
and "squeegee", but there are two objects with one
word in each name, then it should clearly be parsed
as two consecutive noun-phrases, and therefore the
sentence matches the template

        give (x) (y)

> >> "Coloca en la caja la pelota" (Put in the box the ball)

English does have that sort of thing,
"give x to y" vs "give y x" being an example.
These can be handled using alternative templates
for the same command.

>         Meliton Rodriguez, from 117 room

Greg, from room 408
But how many room 408's are there in the world?
Perhaps we should give our rooms URLs? In that case mine could be
room://cosc.canterbury.ac.nz/level4/408

Parser construction (was: Inform in other languages) PAZ SALGADO 5/28/96 12:00 AM

Greg Ewing (gr...@cosc.canterbury.ac.nz) wrote:
: Parsing a traditional IF-style command language doesn't

: necessarily require dividing words into the usual categories
: of nouns, adjectives, verbs, prepositions, etc. You can
: get a long way by just having a bunch of patterns to
: match against, e.g.

:         take (x)
:         kick (x) behind (y)

Do you mean that I need to create one template for each verb and for each
different form of using that verb?

Uhm? But the most of verbs can use the same structure (take, drop, and so).

In the other hand, how can you parser using patterns that kind of phrase:

>> say to Lord Dragon "Please, go to the far south and take the gold
fruits in order to save the Sacred Tree. Then return to north and give me
the fruits"

Wow! You need a biiiig pattern.

Again I'm thinking on talking to NPCs.

: Greg, from room 408


: But how many room 408's are there in the world?
: Perhaps we should give our rooms URLs? In that case mine could be
: room://cosc.canterbury.ac.nz/level4/408

        Meliton Rodriguez, from

        life://spain.europe.earth/mad/117

        OK!


Parser construction (was: Inform in other languages) Stefan Jokisch 5/28/96 12:00 AM

ja...@tid.tid.es (PAZ SALGADO) writes:

>Please, yacc is perfect for computer language, but not useful at all for
>natural language. If you want to have a good parser forget the computer

>parser studies and take your old grammar books!

Hm. Infocom claimed that their V6 games use LALR(1) parsers -- this
is exactly the type of parser YACC generates. I admit that I haven't
gone through Z-code disassemblies to confirm this, but the invention
of stack-handling opcodes (such as POP_STACK to remove n items from
a stack) indicates that this is correct.

-- Stefan

Parser construction (was: Inform in other languages) PAZ SALGADO 5/28/96 12:00 AM

Stefan Jokisch (jok...@euklid.informatik.uni-dortmund.de) wrote:
: ja...@tid.tid.es (PAZ SALGADO) writes:

Well, more and more, I dislike Inform system. I'm starting to think
that Inform doesn't understand nothing on natural language, I mean,
that it is useful for order style interfaces (like player inputs)
but what about talking NPCs?

As I have said several times in this group I think that NPCs are, IMHO,
the most important thing in a good (funny) adventure. And I think that
the possibility of make question to them about something (not only make orders)
are a very powerful option.


   Sorry. My english is very *spanish-ed*. I make phrases too long.

        Meliton Rodriguez, from
        life://spanish.europe.earth/mad/117

Parser construction (was: Inform in other languages) Matthew T. Russotto 5/28/96 12:00 AM

In article <4oesrc$8...@fbi-news.Informatik.Uni-Dortmund.DE>,

Hmm.  So has anyone deciphered the state machines and reconstructed the
grammars?  Except Journey, of course -- Journey doesn't have a parser.
--
Matthew T. Russotto      russ...@pond.com     russ...@his.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."

Parser construction (was: Inform in other languages) Magnus Olsson 5/29/96 12:00 AM

In article <4oesrc$8...@fbi-news.informatik.uni-dortmund.de>,

Stefan Jokisch <jok...@euklid.informatik.uni-dortmund.de> wrote:
>ja...@tid.tid.es (PAZ SALGADO) writes:
>
>>Please, yacc is perfect for computer language, but not useful at all for
>>natural language. If you want to have a good parser forget the computer
>>parser studies and take your old grammar books!
>
>Hm. Infocom claimed that their V6 games use LALR(1) parsers -- this
>is exactly the type of parser YACC generates. I admit that I haven't
>gone through Z-code disassemblies to confirm this, but the invention
>of stack-handling opcodes (such as POP_STACK to remove n items from
>a stack) indicates that this is correct.

But then, on the other hand, the language accepted by Infocom's parsers
(or any other IF parser that I know of) is not natural language, just
a simulation.

IMHO, what IF needs right now in the terms of user interface is not
better parsers, but better ways of modelling the player-world interaction.
For example, what use is the world's best parser if there is no way
of distinguishing between looking directly at an object, giving it a
cursory look from some distance, examining it in detail, or glancing
at it over your shoulder?

--
Magnus Olsson (m...@df.lth.se)

Parser construction (was: Inform in other languages) PAZ SALGADO 5/29/96 12:00 AM

Magnus Olsson (m...@marvin.df.lth.se) wrote:
: IMHO, what IF needs right now in the terms of user interface is not

: better parsers, but better ways of modelling the player-world interaction.
: For example, what use is the world's best parser if there is no way
: of distinguishing between looking directly at an object, giving it a
: cursory look from some distance, examining it in detail, or glancing
: at it over your shoulder?

Your I-Fs vision is, IMHO, very different to mine. You are thinking about
puzzles, so you need a better and with more details description of world.
I think that issue is very important. But I'm thinking about NPCs, in order to
make I-Fs living; so I need too a better parsing.

I bore solving puzzle, but I enjoy a lot talking with a good NPCs.

        Meliton Rodriguez, from
        life://spain.europe.earth/mad/117


Parser construction (was: Inform in other languages) Trevor Barrie 5/30/96 12:00 AM

Greg Ewing <gr...@cosc.canterbury.ac.nz> wrote:

>You could distinguish between nouns and adjectives, but that can
>lead to difficulties with words like "pot" which can be either.

How do you use "pot" as an adjective? (Yeah, I know it's irrelevant to
your point, it just seems like an odd choice of example.)


Parser construction (was: Inform in other languages) Bruce Stephens 5/30/96 12:00 AM

"take the pot plant".  (Just before planting it in the plant pot.)


--
Bruce Stephens                        | email: B.Ste...@math.ruu.nl
Utrecht University              | telephone: +31 30 2534630
Department of Mathematics       | telefax:   +31 30 2518394
P.O. Box 80010, 3508 TA Utrecht |
The Netherlands                 |

Visions of future IF (was: Parser construction (was: Inform in other languages)) Magnus Olsson 5/30/96 12:00 AM

In article <4oh69u$k...@tid.tid.es>, PAZ SALGADO <ja...@tid.tid.es> wrote:
>Magnus Olsson (m...@marvin.df.lth.se) wrote:
>: IMHO, what IF needs right now in the terms of user interface is not
>: better parsers, but better ways of modelling the player-world interaction.
>: For example, what use is the world's best parser if there is no way
>: of distinguishing between looking directly at an object, giving it a
>: cursory look from some distance, examining it in detail, or glancing
>: at it over your shoulder?
>
>Your I-Fs vision is, IMHO, very different to mine. You are thinking about
>puzzles, so you need a better and with more details description of world.

No, that's not really what I'm thinking of. I'm actually getting
more and more sympathetic to the "puzzle-less" school of IF, though I
don't think that puzzles should be abolished altogether, just that the
emphasis in IF should be on other things than puzzles.

I don't want better modelling of the player-world interaction because
I want to make better puzzles, although it would certainly give the
opportunity for that, but because I want to ease some of the
restrictions imposed by the medium. An imperfect world model gets in the
way of mimesis.

Note that I'm not advocating IF as a simulation of reality.

>I think that issue is very important. But I'm thinking about NPCs, in order to
>make I-Fs living; so I need too a better parsing.
>
>I bore solving puzzle, but I enjoy a lot talking with a good NPCs.

Of course, if we are to talk to NPC's in a realistic manner, we need a better
parser, but that's the easy part of it. The difficult part is getting the
NPC to understand what you're saying, and to react in a sensible manner.

Today's NPC's are intolerably stupid :-). Improving the parser without making
the NPC's smarter will only make their stupidity more apparent.

I'd be overjoyed to have an NPC that reacted in an even remotely
intelligent way to the standard "show/give <foo> to <actor>", "ask
<actor> about <foo>" and "tell <actor> about <foo>". The ability to
type "Troll, could you please tell me what happens if I press the red
button?" would of course be nice, but only useful if the troll had the
intelligence to reply to it.

--
Magnus Olsson (m...@df.lth.se)

Parser construction (was: Inform in other languages) Andrew Hatchell 5/30/96 12:00 AM

In article <STEPHENS.96...@bommel.math.ruu.nl>,

Bruce Stephens <step...@math.ruu.nl> wrote:
>> "Trevor" == Trevor Barrie <tba...@cycor.ca> writes:

>>> Greg Ewing <gr...@cosc.canterbury.ac.nz> wrote:
>>> You could distinguish between nouns and adjectives, but that can
>>> lead to difficulties with words like "pot" which can be either.

>> How do you use "pot" as an adjective? (Yeah, I know it's irrelevant
>> to your point, it just seems like an odd choice of example.)

>"take the pot plant".  (Just before planting it in the plant pot.)

I believe "pot plant" is actually just two nouns making a phrase, not
an adjective use of "pot" (this would be the slang meaning of pot as
marijuana).  A plant in a pot is a "potted plant", and I can't
think of any other use of "pot" as an adjective.  Of course, it can be a
verb ("I will pot the plant in the pot"), which still illustrates
the problem quite nicely.

        Andrew


Parser construction (was: Inform in other languages) Gareth Rees 5/30/96 12:00 AM

Trevor Barrie <tba...@cycor.ca> wrote:
> How do you use "pot" as an adjective?

Any noun can (in the right circumstances) be co-opted into use as an
adjective (this is called the "attributive" use of the noun).  For
example:

    pot plant
    oil tanker
    flag pole
    rock garden

Note the difference between "oil tanker" (noun used as adjective) and
"oily tanker" (ordinary adjective).  Or "rock garden" and "rocky
garden".

Followups to alt.usage.english.

--
Gareth Rees

Visions of future IF (was: Parser construction (was: Inform in other languages)) PAZ SALGADO 5/30/96 12:00 AM

Magnus Olsson (m...@marvin.df.lth.se) wrote:
: Of course, if we are to talk to NPC's in a realistic manner, we need a better

: parser, but that's the easy part of it. The difficult part is getting the
: NPC to understand what you're saying, and to react in a sensible manner.

: Today's NPC's are intolerably stupid :-). Improving the parser without making
: the NPC's smarter will only make their stupidity more apparent.

Not at all. If you have a good parsing at least the NPCs wouldn't say

>> He seems not to understand you.

the whole time.

: I'd be overjoyed to have an NPC that reacted in an even remotely


: intelligent way to the standard "show/give <foo> to <actor>", "ask
: <actor> about <foo>" and "tell <actor> about <foo>". The ability to
: type "Troll, could you please tell me what happens if I press the red
: button?" would of course be nice, but only useful if the troll had the
: intelligence to reply to it.

Please, I hate "ask nobody about the red thing" or "tell the clown about
his dead wife". That kind of *talking* are worst than the boring (and
terrible easy) graphic-adventures *talking* system (with just a list
of things that you can say).

Of course, you need lots of work in order to make NPCs a bit intelligence,
I write pages and pages of code only for NPCs.Any case are a lot of themes
(about you can ask an NPC) that are *general culture* and you can reuse
code for a lot of different NPCs. For example, if you ask for the bus stop
almost anybody may answer you, so you only to make the answer one time
and reuse the code (or in Inform and TADS, make that all *citizens* knows
where is the bus stop).

I'd like the Troll answers:

>> Ho, ho, try human, try but just count down 20.
(while Troll run away)

                Meliton Rodriguez from
                life://spain.europe.earth/mad/117


Parser construction (was: Inform in other languages) Matthew Russotto 5/30/96 12:00 AM

   > pot plant
   Which plant do you mean, the azalea or the marijuana plant?

   > pot plant

   The marijuana plant is now in the pot.


Parser construction (was: Inform in other languages) Phil Goetz 5/30/96 12:00 AM

In article <4oh69u$k...@tid.tid.es>, PAZ SALGADO <ja...@tid.tid.es> wrote:

I developed a parser in the 1980's.  I initially added some sophisticated
capabilities that other parsers didn't have.  I took many of these out
because it was IMPOSSIBLE TO USE THEM.  The world simulation was not
complicated enough for things such as adverbs to have any use.

I am so completely convinced that world simulation is more important
to advance than parser sophistication, that I will not be swayed at
all by your posts unless you list several specific examples of ways in
which a fancier parser (parsing the command line) could improve your NPCs.

It is true it would be nice to parse things like

"Did you see Jim come into this room today?"

and get an answer from the NPC, but note that the tricky part is not
the parse, but the knowledge representation and retrieval.

Phil Go...@cs.buffalo.edu

Parser construction (was: Inform in other languages) Paul David Doherty 5/31/96 12:00 AM

In article <Ds7y4...@midway.uchicago.edu>,

Andrew Hatchell <a-hat...@uchicago.edu> wrote:
>>> How do you use "pot" as an adjective? (Yeah, I know it's irrelevant
>>> to your point, it just seems like an odd choice of example.)
>
>>"take the pot plant".  (Just before planting it in the plant pot.)
>
>I believe "pot plant" is actually just two nouns making a phrase, not
>an adjective use of "pot" (this would be the slang meaning of pot as
>marijuana).

In the above example (taken from Magnetic Scrolls' THE PAWN) the pot
plant is indeed a marijuana plant. Pot is used as an adjective.

-- Dave


Parser construction (was: Inform in other languages) PAZ SALGADO 5/31/96 12:00 AM

Phil Goetz (go...@cs.buffalo.edu) wrote:
: I am so completely convinced that world simulation is more important

: to advance than parser sophistication, that I will not be swayed at
: all by your posts unless you list several specific examples of ways in
: which a fancier parser (parsing the command line) could improve your NPCs.

An example:

  I'm working now in a I-F called "APACHE". It is based in a real history
at the town of Cibicu (I expect to write it well); but I just want to
write about american indian. The fisrt part of adventure occurs in a
a little indian town and its enviroment. I just no have more than several
kowas (apache's house), no laberynth, no puzzles at all (not in the way
take that key to open this door, no object-puzzle), why? because in kowas
there are no lots of things.

You must to hunt a bear in order to be a warrior (it is not very very apache
way but forget it). You can't do it just only with your tomahawk, you need
help. You need:

        1. To found bears --> asking to the old hunters in your town.
           (I need adverbs. "What" and "Where" are adverbs in spanish)
        2. Obtain the help of one friend. In order to these you need
to talk him, until get his help.
        3. Obtain a good bow, talking to cheif until get his freindship.
        4. Locate onyx stones --> asking to other town habitants, etc.

   In the whole apache site there are only ten important objects, and
ten NPCs you can talk to.

   If I only have to type:

>> talk to chief about his wife.

   or so, the adventure could be very easy and boring.

   So I need to type:

>> talk to chief "What about your wife?"

   (You may remember that I talk spanish, and usually when we talk we
do lots of subordinate phrases,...)


    Meliton Rodriguez, from 117 room

Parser construction (was: Inform in other languages) Magnus Olsson 5/31/96 12:00 AM

In article <4om220$a...@joker.rz.hu-berlin.de>,

It's an interesting point that English nouns are used attributively to
such a large extent. In most Germanic languages compound nouns are
used instead; this possibility exists in English as well (pot-plant
rather than pot plant) but isn't very common.

I think what confused the first poster was the distinction between
the "static" word classes nouns vs. adjectives, and the "dynamic"
uses of the noun "pot". An adventure parser (for the English language)
should not make a rigid distinction between nouns and adjectives, or
should at least allow the same word to be both a noun and an adjective.
Inform makes no distinction at all; a "pot plant" can just as well be
referenced as a "plant pot", a "pot" or a "plant".

--
Magnus Olsson (m...@df.lth.se)

Parser construction (was: Inform in other languages) Kenneth Fair 6/1/96 12:00 AM

In article <4onurq$o...@news.lth.se>, m...@marvin.df.lth.se (Magnus Olsson) wrote:


>It's an interesting point that English nouns are used attributively to
>such a large extent. In most Germanic languages compound nouns are
>used instead; this possibility exists in English as well (pot-plant
>rather than pot plant) but isn't very common.

I don't know that it's *that* uncommon.  There are quite a few compound
nouns that have gone the "pan cake" -> "pan-cake" -> "pancake" route.
Not nearly the same as German, of course, but not insubstantial.

--
KEN FAIR - U. Chicago Law  | <http://student-www.uchicago.edu/users/kjfair>
Of Counsel, U. of Ediacara | Power Mac! | CABAL(tm) | I'm w/in McQ - R U?

  The Internet was not created for companies to make money from.

Parser construction (was: Inform in other languages) Matthew T. Russotto 6/2/96 12:00 AM

In article <4onurq$o...@news.lth.se>,
Magnus Olsson <m...@marvin.df.lth.se> wrote:

}I think what confused the first poster was the distinction between
}the "static" word classes nouns vs. adjectives, and the "dynamic"
}uses of the noun "pot". An adventure parser (for the English language)
}should not make a rigid distinction between nouns and adjectives, or
}should at least allow the same word to be both a noun and an adjective.
}Inform makes no distinction at all; a "pot plant" can just as well be
}referenced as a "plant pot", a "pot" or a "plant".

Which unfortunately is wrong -- if you've got two objects, one of which is
a ceramic container you put plants in, and another which is a specimen of
cannibis sativa, the former is a "pot" or a "plant pot" and the latter
is a "plant" or a "pot plant".  The disambiguator probably goes
nuts...


--
Matthew T. Russotto      russ...@pond.com     russ...@his.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."

Parser construction (was: Inform in other languages) Adam J. Thornton 6/2/96 12:00 AM

In article <4osh6i$4...@wanda.phl.pond.com>,

Matthew T. Russotto <russ...@wanda.phl.pond.com> wrote:
>Which unfortunately is wrong -- if you've got two objects, one of which is
>a ceramic container you put plants in, and another which is a specimen of
>cannibis sativa, the former is a "pot" or a "plant pot" and the latter
>is a "plant" or a "pot plant".  The disambiguator probably goes
>nuts...

Oh, no more so than usual with ADV.T.

"Which pot plant do you mean, the pot plant or the pot plant?"

Adam
--
ad...@phoenix.princeton.edu | Viva HEGGA! | Save the choad! | 64,928 | Fnord
"Double integral is also the shape of lovers curled asleep":Pynchon | Linux
Thanks for letting me rearrange the chemicals in your head. | Team OS/2
You can have my PGP passphrase when you pry it from my cold, dead brain.

Parser construction (was: Inform in other languages) Greg Ewing 6/4/96 12:00 AM

PAZ SALGADO wrote:
> >> say to Lord Dragon "Please, go to the far south and take the gold
> fruits in order to save the Sacred Tree. Then return to north and give me
> the fruits"
>
> Wow! You need a biiiig pattern.

Or a hierarchy of patterns:

command: say to (character) "(commands)"
command: go to (location)
command: return to (location)
command: take (object)
command: give (character) (object)
command: (command) in order to (command)
command: please (commands)

commands: (command)
commands: (command) and (commands)
commands: (command) then (commands)

Greg

Parser construction (was: Inform in other languages) Greg Ewing 6/4/96 12:00 AM

PAZ SALGADO wrote:
> But I'm thinking about NPCs, in order to
> make I-Fs living; so I need too a better parsing.

Seems to me you don't just need better parsing,
but better AI in general. I don't think you can
separate parsing and understanding when you're
trying to simulate a person.

Supposing your NPC can parse the question you
ask, what is he going to do with it? Maybe
approaching NPC interaction by asking for a
better parser is starting at the wrong end.

Maybe when we know how to build an NPC which has
a non-trivial understanding of the simulated
world he lives in, it will become more obvious
what subset of English we need to hold a
conversation with him about it, and therefore
what is required to parse it.

Greg

Parser construction (was: Inform in other languages) Greg Ewing 6/4/96 12:00 AM

PAZ SALGADO wrote:
>         1. To found bears --> asking to the old hunters in your town.
>            (I need adverbs. "What" and "Where" are adverbs in spanish)

In English they're pronouns, but that's beside the point...

>    So I need to type:
>
> >> talk to chief "What about your wife?"

You could make exactly this work today in Inform or Tads
by defining a *verb* called "what" with a preposition
"about". Then you could say

        chief, what about your wife

and it would have exactly the same effect as

        ask chief about wife

So this example does *not* demonstrate the need for any further
parsing mechanisms.

> or so, the adventure could be very easy and boring.

I don't see that it's much less boring saying "what about x"
to every person in turn than doing "talk to y about x"
to every person in turn.

> 2. Obtain the help of one friend. In order to these you need
>    to talk him, until get his help.
> 3. Obtain a good bow, talking to cheif until get his freindship.
 
These will need much, much more than just a parser to make
them interesting.

> In the whole apache site there are only ten important objects, and
> ten NPCs you can talk to.

So you've got 100 combinations of "say to x, what about y"
to go through. Even if I can phrase the question 100 different
ways, I'm still going to want varied and interesting responses
to avoid getting bored, and that requires much more than just
parsing!

>    (You may remember that I talk spanish, and usually when we talk we
> do lots of subordinate phrases,...)

I don't think that tendency is confined to the Spanish :-)

Greg

Parser construction (was: Inform in other languages) Greg Ewing 6/4/96 12:00 AM

Trevor Barrie wrote:
>
> How do you use "pot" as an adjective?

By describing something as a "pot plant".

> (it just seems like an odd choice of example.)

I only used it because of earlier mention of
phrases like "plant the pot plant in the pot"
which confuse parsers that try to assign parts
of speech to words before doing anything else.

Greg

Parser construction (was: Inform in other languages) Greg Ewing 6/4/96 12:00 AM

Andrew Hatchell wrote:
>
> I believe "pot plant" is actually just two nouns making a phrase, not
> an adjective use of "pot"

It distinguishes the particular plant being referenced from
other kinds of plant, so I think it makes sense to think
of it as an adjective.

But my point was that you don't necessarily have to make
any distinction - just treat them all as words that can
be part of the name of an object in certain contexts.

Greg

Parser construction (was: Inform in other languages) Greg Ewing 6/4/96 12:00 AM

Magnus Olsson wrote:
> Inform makes no distinction at all; a "pot plant" can just as well be
> referenced as a "plant pot", a "pot" or a "plant".

Which incidentally points up a weakness - if you have both
a "plant pot" and a "pot plant" in the room, you're
in trouble!

Solution - prefer an object whose name contains words in
the same order as the player typed them. (Inform might
already do this - I've never tested it.)

> Magnus Olsson (m...@df.lth.se)

Greg

Parser construction (was: Inform in other languages) PAZ SALGADO 6/4/96 12:00 AM

Greg Ewing (gr...@cosc.canterbury.ac.nz) wrote:

Something:

        1. You don't need some of this patterns (For example,
"Please (command)"); but you need manage of puntuaction (I
expect to spelling well) like *,* or *.*

        2. If you make patterns with each verb, each conjuntion (and, then...),
each case of subordinates (in order to...) you are doing a lot of work,
much more than try to create a *inteligent* parser.

        Anyway I have been asking about english teaching, and I conclude that
the normal way of learning grammar is pattern-like. I think the problem
is that spanish grammar natural point of view is more structural,
Chomsky-like. Talking spanish, we *eat* lots of words (for example the
subject of phrase), and make lots of subordination levels.

        Well I don't know...

                Meliton Rodriguez, from 117 room
is that spanish natural point of view are chomsky-like


Parser construction (was: Inform in other languages) PAZ SALGADO 6/4/96 12:00 AM

Greg Ewing (gr...@cosc.canterbury.ac.nz) wrote:

: PAZ SALGADO wrote:
: > But I'm thinking about NPCs, in order to
: > make I-Fs living; so I need too a better parsing.

: Seems to me you don't just need better parsing,
: but better AI in general. I don't think you can
: separate parsing and understanding when you're
: trying to simulate a person.

I'm not trying to *simulate a person*. I just want to
make NPCs less stupid.

: Supposing your NPC can parse the question you


: ask, what is he going to do with it? Maybe
: approaching NPC interaction by asking for a
: better parser is starting at the wrong end.

: Maybe when we know how to build an NPC which has
: a non-trivial understanding of the simulated
: world he lives in, it will become more obvious
: what subset of English we need to hold a
: conversation with him about it, and therefore
: what is required to parse it.

In order to improve I-F we need both, more
realistic description of worlds and better
parsing. NPCs don't need to know about world
in the AI sense, in which they can go to the
*virtual park* and look the *virtual flowers*
in order to answer you if there is "flowers
in the park".

You only need to write:

>> If your are asked:
        
        THEREIS FLOWERS INPARK ?

>> You must answer:

        Oh doctor, yeah!

I think try to have a knowing-data-base for each
NPC in the AI way, could be too much for ours poor
GAMES of reality simulation; but we can simulate
clever NPCs...

        Meliton Rodriguez, from 117 room

Parser construction (was: Inform in other languages) PAZ SALGADO 6/4/96 12:00 AM

Greg Ewing (gr...@cosc.canterbury.ac.nz) wrote:

: >    So I need to type:


: >
: > >> talk to chief "What about your wife?"

: You could make exactly this work today in Inform or Tads
: by defining a *verb* called "what" with a preposition
: "about". Then you could say

:         chief, what about your wife

: and it would have exactly the same effect as

:         ask chief about wife

: So this example does *not* demonstrate the need for any further
: parsing mechanisms.

No, no. You can do:

>> chief "What about your wife?"

Chief said: "Oh, you know. I still remember her."

>> chief "Sorry, I don't know she was dead"

Cheif said: "Don't worry."

>> chief "She was a good person"

Cheif said: "Yes, she do"


And so on... It's terrible difficult, but I enjoy
with it. In the other hand with *talk chief about his wife*
you only must to write the same phrase three times!


: > In the whole apache site there are only ten important objects, and


: > ten NPCs you can talk to.

: So you've got 100 combinations of "say to x, what about y"
: to go through. Even if I can phrase the question 100 different
: ways, I'm still going to want varied and interesting responses
: to avoid getting bored, and that requires much more than just
: parsing!

Oh, please, if you try to talk about your shoes to the chief
he could think you are getting mad!


        Meliton Rodriguez, from 117 room


Parser construction (was: Inform in other languages) Magnus Olsson 6/4/96 12:00 AM

In article <4osmfs$1...@cnn.princeton.edu>,

Adam J. Thornton <ad...@flagstaff.princeton.edu> wrote:
>In article <4osh6i$4...@wanda.phl.pond.com>,
>Matthew T. Russotto <russ...@wanda.phl.pond.com> wrote:
>>Which unfortunately is wrong -- if you've got two objects, one of which is
>>a ceramic container you put plants in, and another which is a specimen of
>>cannibis sativa, the former is a "pot" or a "plant pot" and the latter
>>is a "plant" or a "pot plant".  The disambiguator probably goes
>>nuts...
>
>Oh, no more so than usual with ADV.T.
>
>"Which pot plant do you mean, the pot plant or the pot plant?"

Huh?

In TADS, you have a pot plant with
adjective = 'pot'
noun = 'plant'

and a plant pot with
adjective = 'plant'
noun = 'pot'

The disambiguator utilizes the difference between adjectives and nouns so
that if only the pot plant is present, then "take pot" will take the
plant, but if both the pot plant and the plant pot are present, the pot
will be taken.

In Inform, on the other hand, the standard library expects you to declare
both the pot plant and the plant pot with
name = "pot" "plant"
and there is no way for the parser to disambiguate the phrase "pot plant"
if both are present.

I think I have seen an extension to the Inform library that adds adjectives
to the parser.

--
Magnus Olsson (m...@df.lth.se)

Parser construction (was: Inform in other languages) Adam J. Thornton 6/5/96 12:00 AM

In article <4p0on6$m...@news.lth.se>,

Magnus Olsson <m...@marvin.df.lth.se> wrote:
>In article <4osmfs$1...@cnn.princeton.edu>,
>Adam J. Thornton <ad...@flagstaff.princeton.edu> wrote:
>>In article <4osh6i$4...@wanda.phl.pond.com>,
>>Matthew T. Russotto <russ...@wanda.phl.pond.com> wrote:
>>>is a "plant" or a "pot plant".  The disambiguator probably goes
>>>nuts...
>>Oh, no more so than usual with ADV.T.
>>"Which pot plant do you mean, the pot plant or the pot plant?"

>Huh?


>The disambiguator utilizes the difference between adjectives and nouns so
>that if only the pot plant is present, then "take pot" will take the
>plant, but if both the pot plant and the plant pot are present, the pot
>will be taken.

I was only making a snide little joke about the

"Which X do you mean, the X or the X?" bug that crops up quite often in
TADS games.

I remember one particularly nasty one coming up during Rylvania's
betatesting.

Adam
--
ad...@phoenix.princeton.edu | Viva HEGGA! | Save the choad! | 64,928 | Fnord
"Double integral is also the shape of lovers curled asleep":Pynchon | Linux
Thanks for letting me rearrange the chemicals in your head. | Team OS/2
You can have my PGP passphrase when you pry it from my cold, dead brain.

Parser construction (was: Inform in other languages) Greg Ewing 6/5/96 12:00 AM

Kenneth Fair wrote:
>
> There are quite a few compound
> nouns that have gone the "pan cake" -> "pan-cake" -> "pancake" route.
> Not nearly the same as German, of course,

Not as long, either!

I once experienced a lecture by a German speaker who
did this freely with *english* words. His overheads
were full of words like "operatingsystem" and
"programminglanguage", which I found rather
entertaining.

German is an amazing language. It's a mystery
to me how Germans can speak it with a straight
face...

> KEN FAIR - U. Chicago Law  | <http://student-www.uchicago.edu/users/kjfair>

Greg

Parser construction (was: Inform in other languages) Thomas Nilsson 6/6/96 12:00 AM

Magnus Olsson wrote:
> >>cannibis sativa, the former is a "pot" or a "plant pot" and the latter
> >>is a "plant" or a "pot plant".  The disambiguator probably goes
> >>nuts...
> >
> >Oh, no more so than usual with ADV.T.
> >
> >"Which pot plant do you mean, the pot plant or the pot plant?"
>
> Huh?
>
> In TADS, you have a pot plant with
> adjective = 'pot'
> noun = 'plant'
>
> and a plant pot with
> adjective = 'plant'
> noun = 'pot'
>
> The disambiguator utilizes the difference between adjectives and nouns so
> that if only the pot plant is present, then "take pot" will take the
> plant, but if both the pot plant and the plant pot are present, the pot
> will be taken.
>

Just for the record, the above also goes for Alan:

        Object pot_plant At l
          Name plant pot
        End Object.

        Object plant_pot At l
          Name pot plant
        End Object.

There is a plant pot and a pot plant here.

> x pot
plant pot

> x plant
pot plant

> x pot plant
pot plant

> x plant pot
plant pot


--
"Little languages go a long way..."
(ThoNi of ThoNi&GorFo Adventure Factories in 1985)
------------------------------------------------------------------------
Thomas Nilsson                                Phone Int.: (+46) 13 12 11 67
Stenbrötsgatan 57                        Phone Nat.: 013 - 12 11 67
S-582 47 LINKÖPING                         Email: th...@softlab.se
SWEDEN                                        alan-r...@softlab.se for info
------------------------------------------------------------------------

Parser construction (was: Inform in other languages) Greg Ewing 6/7/96 12:00 AM

PAZ SALGADO wrote:
>
> I'm not trying to *simulate a person*. I just want to
> make NPCs less stupid.

I don't see what the difference is.

> NPCs don't need to know about world
> in the AI sense, in which they can go to the
> *virtual park* and look the *virtual flowers*
> in order to answer you if there is "flowers
> in the park".

But it seems to me that's exactly what he
*does* need to be able to do if he is not
to appear stupid outside of a very narrow
and arbitrarily-chosen domain.

> You only need to write:
>
> >> If your are asked:
>
>         THEREIS FLOWERS INPARK ?
>
> >> You must answer:
>
>         Oh doctor, yeah!

But this is no improvement over what we have now,
for two reasons:

(1) Our current parsers can *already* parse a
    sentence like that.

(2) What if the player asks about some combination that
    the author hasn't provided for? The best the NPC can
    do is say "I don't know" or something to that effect.
    This is hardly going to strike the player as a
    remarkable show of intelligence.

On the other hand, suppose you treat this by having
a general pattern "is|are there [any] (x) in (y)",
and handle it using a piece of code which actually
examines the x to see if there is a y in it.
Now, the NPC can accurately answer any such question
about anything in the game vocabularly. The NPC
is now exhibiting *true* intelligence - not faked,
but the real thing!

> I think try to have a knowing-data-base for each
> NPC in the AI way, could be too much for ours poor
> GAMES

An exhaustive list of all the facts that the NPC
ought to be able to recite as an answer to a question
would certainly be prohibitive. But even a small
amount of ability to deduce such facts from the
information already present in the world would
be a big improvement.

> we can simulate clever NPCs...

If you mean by that "we can fake clever NPCs",
I don't agree. Our parsers are already powerful
enough to let the player expose such fakery
very easily.

As far as I can see, the only way to make NPCs
*seem* intelligent, and do it convincingly,
is to actually *make* them intelligent. Our
parsers are already too powerful. Making them
more powerful without beefing up our NPCs'
brains to match will only make matters worse!

>         Meliton Rodriguez, from 117 room

Greg, whose body is in room 408, but whose
mind is in some unspecified place in cyberland

Parser construction (was: Inform in other languages) Greg Ewing 6/7/96 12:00 AM

PAZ SALGADO wrote:
>
> I conclude that
> the normal way of learning grammar is pattern-like.

Yes, I suspect the human brain doesn't parse language
using a grammar, but by matching it against a large number
of somewhat fuzzy patterns that interact with each other.

> spanish grammar natural point of view is more structural,
> Chomsky-like.

I don't know much about Spanish, but what you seem to be
saying is that Spanish grammar is more regular than English,
so that it's easier to describe it using formal rules.
If that's the case, you will have an easier time writing
programs to deal with it.

> Talking spanish, we *eat* lots of words (for example the
> subject of phrase),

Not sure what you mean by that - do you mean that many words
can be omitted without losing the meaning?

> and make lots of subordination levels.

English sentences can be made very complicated too, but
if things get too convoluted the listener can easily get
lost.

For instance, "Fred found the cheese that the mouse that the cat that
the dog chased caught stole" makes perfectly good sense if
you take enough time to pick it apart, but it's nearly
impossible to understand something like that in real
time.

That suggests to me that the brain can't cope with
hierarchical sentence structures that go more than
one or two levels deep.

Our ability to intuitively apply grammar rules that
connect widely separated parts of a sentence together
also seems to be limited.

It's interesting to study
some commonly made grammatical "errors", such as
"Bob went to the pictures with Fred and I."
Many people say things like that even though they would
never say "Bob went to the pictures with I." Even
if you know intellectually what it should be
(Bob went to the pictures with Fred and me) it's
still likely to slip out the wrong way if you're
not concentrating.

What seems to happen is that we're taught (or pick
up) that "Fred and I went to the pictures" is right
but "Fred and me went to the pictures" is wrong.
To implement this, our pattern-forming mechanism
installs a pattern "<noun> -> <name> and I". But there is
nothing (or only something relatively weak) to
stop this pattern being applied to the object
of a sentence instead of the subject.

To grammar purists this is wrong, but the
listener will have no trouble understanding
what you mean even as he chuckles into his
palm over your ignorance...

What I'm trying to say is that if we want to
minimic the way humans understand language,
we're probably going to need something much
fuzzier than a formal grammar.

Maybe when we learn to build neural networks
that do something useful, we'll be able to
just give our NPC a blank brain and let
him learn for himself!

Greg

Parser construction (was: Inform in other languages) PAZ SALGADO 6/7/96 12:00 AM

Greg Ewing (gr...@cosc.canterbury.ac.nz) wrote:
: But it seems to me that's exactly what he

: *does* need to be able to do if he is not
: to appear stupid outside of a very narrow
: and arbitrarily-chosen domain.

Exact!

: But this is no improvement over what we have now,
: for two reasons:

: (1) Our current parsers can *already* parse a
:     sentence like that.

Do it? For instance, can it analyze just with patterns something like:

>>> Say to Lord Dragon: "Please, go to South, and say to the Old Sage: "go to
the north", then go to the north"

I can do it with my CAECHO? (in spanish) and the Sage (if he want) appear
from south with dragon two turns after.

: (2) What if the player asks about some combination that


:     the author hasn't provided for? The best the NPC can
:     do is say "I don't know" or something to that effect.
:     This is hardly going to strike the player as a
:     remarkable show of intelligence.

: On the other hand, suppose you treat this by having
: a general pattern "is|are there [any] (x) in (y)",
: and handle it using a piece of code which actually
: examines the x to see if there is a y in it.
: Now, the NPC can accurately answer any such question
: about anything in the game vocabularly. The NPC
: is now exhibiting *true* intelligence - not faked,
: but the real thing!

OK! I have use this kind of code some times, perhaps I doesn't
choose correct example the last message.

Well, I think all can be done make a biiig list of patterns
I'd just want to say that I think it could be better put
some work into the parser and get off from code.

        Meliton Rodriguez, from 117 room        

Parser construction (was: Inform in other languages) PAZ SALGADO 6/7/96 12:00 AM

Greg Ewing (gr...@cosc.canterbury.ac.nz) wrote:
: Yes, I suspect the human brain doesn't parse language

: using a grammar, but by matching it against a large number
: of somewhat fuzzy patterns that interact with each other.

I'm not so sure.

: > spanish grammar natural point of view is more structural,


: > Chomsky-like.
: I don't know much about Spanish, but what you seem to be
: saying is that Spanish grammar is more regular than English,
: so that it's easier to describe it using formal rules.
: If that's the case, you will have an easier time writing
: programs to deal with it.

Well, is more grammar regular but much more irregular in
verbs forms, and similar things.

: > Talking spanish, we *eat* lots of words (for example the


: > subject of phrase),
: Not sure what you mean by that - do you mean that many words
: can be omitted without losing the meaning?

Aha! That is. We omitte (correct spelling?) 'I', 'We','She'... the whole time
And other similar construction.

: For instance, "Fred found the cheese that the mouse that the cat that


: the dog chased caught stole" makes perfectly good sense if
: you take enough time to pick it apart, but it's nearly
: impossible to understand something like that in real
: time.

I'm affraid this phrase can be a spanish normal phrase (well
perhaps not in that class of subordination)

*Le toco perder todo el dinero que habia ganado en aquel casino que
tantos recuerdos le traian de Monica, aquella rubia que le presento Rafael*

The previuos one can be a normal phrase, and the subject start
after "toco", the rest of the phrase are the subject!

: That suggests to me that the brain can't cope with


: hierarchical sentence structures that go more than
: one or two levels deep.

Uhmmm... In spanish the only way in order to get which word is the
subject lots of time is changing the possible word into its plural
form (tree --> trees). If the verbs changes then this word is the subject.
This kind of behavior (?) is called *concordancia*. Almost all spanish
talker use *concordancia* better than get the real subject, but it
means than their brain analyze the phrase in order to get correct
*concordancia* more than just constrast several patterns.

: Maybe when we learn to build neural networks


: that do something useful, we'll be able to
: just give our NPC a blank brain and let
: him learn for himself!

Ow! I don't think we need such kind of NPCs

        Meliton Rodriguez, from 117 room


Parser construction (was: Inform in other languages) John Holder 6/7/96 12:00 AM

Magnus Olsson (m...@marvin.df.lth.se) mentioned in rec.arts.int-fiction that::

> I think I have seen an extension to the Inform library that adds adjectives
> to the parser.

In fact, this extension is in the designers manual, and I use it regularly.
--
John Holder (jho...@nmsu.edu)   http://speedracer.nmsu.edu/~jholder/
"Anyone who considers arithmetic methods of producing random
 digits is, of course, in a state of sin." - John von Neumann
          <<<< Powered by Linux and Dr. Pepper >>>>

Parser construction (was: Inform in other languages) Greg Ewing 6/10/96 12:00 AM

PAZ SALGADO wrote:
>
> I'm affraid this phrase can be a spanish normal phrase (well
> perhaps not in that class of subordination)

The level of subordination is the whole point. Nobody
would say it that way unless they were deliberatly
trying to be obtuse (and then they'd have to write
it down first!) Much more likely they would say
"the cheese that was stolen by the mouse that was
caught by the cat that was chased by the dog".

Now, if you draw a parse tree of the two different
phrases, they both go down to the same depth. But
the latter is perfectly easy to understand at first
hearing, whereas when you listen to the original,
when you get to the bit which goes "chased caught
stole", you think "WHAT???" and your brain gets a
syntax error!

I think that there is an important clue in there
somewhere about how people parse language. We seem
to be able to deal easily with strings of sub-phrases that
only connect with those on either side, but have
trouble making long-range connections between
widely separated parts of a sentence. And we
don't seem to have a very deep "parsing stack".

Whether this has any relevance to NPC conversation
parsing I don't know, but I find it interesting.

> Ow! I don't think we need such kind of NPCs

On the contrary, I think it would be very interesting
to hold a conversation with one...

>         Meliton Rodriguez, from 117 room

Greg

More topics »