Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Why are parsers considered difficult?

950 views
Skip to first unread message

Benjamin Fan

unread,
Jan 29, 2003, 2:24:45 AM1/29/03
to
Why are IF input parsers considered to be difficult to implement?
In previous threads about existing vs. new IF systems, I keep
reading about how writing a good parser is extremely difficult, to
the point that it is the most likely deterrent that would stop
someone from writing their own system.

I can understand why writing a "great" parser might be
difficult, but a pretty good one seems to be easy enough. I wrote
one this evening that parses the following sorts of sentences:

"put the green apple on the wooden desk"
"spit into the brass spittoon"
"edward, get the beautiful parrot"
"give edward the happy parrot"
"get the brass lantern and the tasty food and the key"
"get lantern, food, key"
"give edward the brass lantern, the tasty smelly food, and the brass
oversized duplicate skeleton key"

The parser code is extremely crappy since I ignored most, if not
all, good programming practices. Also, I dumbed down the code to
make it easier to port to other languages such as C. I am releasing
this crappy parser code into the Public Domain. It is at:

http://www.geocities.com/bfan2/if/Parser.java

Ben

--
To get my current email address, concatenate these three strings:
1. "benjamin_fan" 2. "_2002a" 3. "@yahoo.com"
It will look a lot like: xxxxxxxx_yyy_zzzzz @ yahoo . com

Neil Cerutti

unread,
Jan 29, 2003, 9:21:06 AM1/29/03
to
In article <9ea00d5e.03012...@posting.google.com>,

Benjamin Fan wrote:
> Why are IF input parsers considered to be difficult to
> implement? In previous threads about existing vs. new IF
> systems, I keep reading about how writing a good parser is
> extremely difficult, to the point that it is the most likely
> deterrent that would stop someone from writing their own
> system.
>
> I can understand why writing a "great" parser might be
> difficult, but a pretty good one seems to be easy enough. I
> wrote one this evening that parses the following sorts of
> sentences:

You've made a good start.

A parser must be aware of the game state, otherwise it cannot
make correct assumptions, or ask intelligent questions. A parser
generates lists of actions for the world model to carry out, not
a mere breakdown into grammatical sections. At best you've
written a limited front-end to a real parser. A lot of the
complexity, as in a compiler, will be in the back-end.

> "put the green apple on the wooden desk"

Player <Put green_apple desk>

> "spit into the brass spittoon"

Player <SpitIn spittoon>

> "edward, get the beautiful parrot"

Edward <Get parrot>

> "give edward the happy parrot"

Player <Give Edward parrot>

> "get the brass lantern and the tasty food and the key"

Player <Get lantern>
Player <Get key>

> "get lantern, food, key"
etc...

> "give edward the brass lantern, the tasty smelly food, and the brass
> oversized duplicate skeleton key"

Player <Give Edward lantern>
Player <Give Edward food>
Player <Give Edward key>

Here are some sentences a modern parser should recognize:

"drop all"
"take all"
(even a two-word parser needs those two)

"drop all but lamp and sword"
"put everything but sceptre in the boat"
(it musn't generate "Player <PutIn Boat Boat>" as part of
the result)

"take coin"
(when there's two similar coins, or two different coins)
"take seven coins"
"put all dimes in purse"

"unlock door"
("What to you want to unlock the door with?" or make an
assumption)
"get"
("get what?" or make an assumption)

"hello sailor"
Nothing happens here.

--
Neil Cerutti <cer...@trans-video.net>

Andrew Plotkin

unread,
Jan 29, 2003, 11:33:27 AM1/29/03
to
Here, Benjamin Fan <junkaccou...@yahoo.com> wrote:
> Why are IF input parsers considered to be difficult to implement?

Extensibility.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.

Kent Tessman

unread,
Jan 29, 2003, 1:24:36 PM1/29/03
to
"Benjamin Fan" <junkaccou...@yahoo.com> wrote in message
news:9ea00d5e.03012...@posting.google.com...

> Why are IF input parsers considered to be difficult to implement?
> In previous threads about existing vs. new IF systems, I keep
> reading about how writing a good parser is extremely difficult, to
> the point that it is the most likely deterrent that would stop
> someone from writing their own system.
>
> I can understand why writing a "great" parser might be
> difficult, but a pretty good one seems to be easy enough. I wrote
> one this evening that parses the following sorts of sentences:

The "input parser" itself isn't the tough part: it's relatively
straightforward to tokenize and categorize inputs based on some set of
templates.

The tough part is the integration of the parser with the management of the
game world, which means having the functionality of the parser be responsive
to the game state. Accepting that task means opening a whole big sackful of
special cases and other vagaries. Compile-time (and runtime) customization
of parser behavior and flexible, smart disambiguation of objects and
commands are completely necessary for a modern parser and *those* are
difficult to implement. Put a couple hundred objects and a few dozen verbs
in the same game and watch the parser grow like a Chia pet.

And the difference between a "good" parser and a "great" one may be, by
modern standards, the difference between playable and not.

Benjamin Fan

unread,
Jan 29, 2003, 1:44:40 PM1/29/03
to
Neil Cerutti <cer...@trans-video.net> wrote:
> A parser must be aware of the game state, otherwise it cannot
> make correct assumptions, or ask intelligent questions. A parser
> generates lists of actions for the world model to carry out, not
> a mere breakdown into grammatical sections. At best you've
> written a limited front-end to a real parser. A lot of the
> complexity, as in a compiler, will be in the back-end.

I think that there is confusion over definitions. By "parser", I
mean the part that takes player input and applies grammar rules to
separate the input into different parts of speech. That is all the
parser is supposed to do.

The other tasks you mention include taking the output from the
parser, recognizing whether it is valid for the game (if not, printing
error messages or prompting for additional information), and other
tasks related to processing game commands and changing game state. I
call this the Command Handler, and I consider it to be part of the
game engine, separate from the parser.

> "drop all but lamp and sword"

Do players use this "all but" construct that often? This is
trickier, and it would require the parser to recognize and parse "all"
and "everything" direct object phrases differently. (There would have
to be another part of speech, "Exclusion Modifier", for these special
direct objects.)

I agree that writing a sophisticated Command Handler is a more
difficult task, but it does not seem terribly difficult either.
Perhaps when people talk about the the "parser", they actually mean
the combined parser/command_handler/game_engine.

Mike Roberts

unread,
Jan 29, 2003, 2:49:59 PM1/29/03
to
> "Benjamin Fan" <junkaccou...@yahoo.com> wrote:
> Why are IF input parsers considered to be difficult to
> implement?

"Neil Cerutti" <cer...@trans-video.net> replied:


> A parser must be aware of the game state, otherwise it cannot

> make correct assumptions, or ask intelligent questions. [...]


> A lot of the complexity, as in a compiler, will be in the
> back-end.

"Andrew Plotkin" <erky...@eblong.com> replied:
> Extensibility.

"Kent Tessman" <ke...@remove-to-reply.generalcoffee.com>:


> The tough part is the integration of the parser with the
> management of the game world, which means having the
> functionality of the parser be responsive to the game state.

This is all just propaganda! Don't listen to them! They're just trying to
protect their precious monopolies on parsing. This is why all of the
existing IF parser sare closely-guarded secrets: all of their code is hidden
away from public view, and it is not possible to obtain documentation
anywhere about their internals. Just try to get the details on how the
Inform parser works - good luck! If you could, you'd see that it's
incredibly simple inside, and all of these supposed subtle details that
everyone always brings up are just scare tactics to keep people from
attempting "regime change" in the IF parser world.

It should be obvious to everyone that parsing is extremely easy. If it were
so hard, how could literally thousands of humans do it effortlessly every
day in ordinary conversation? Do we have to go to "parsing school" in order
to talk to each other? Of course not! It comes naturally enough to most of
us; the only people who have a lot of trouble with it seem to be those
elected to high political office. Programming a parser should just be a
simple matter of rewriting this everyday knowledge into C++ or the language
of your choice.

I've written my own IF parser before; in fact, I've done it at least twice,
which completely disproves the lies that it's "impossible" to write an IF
parser. My latest attempt took well under three years, so don't let anyone
tell you it's "difficult" - it just takes a little time and effort. (If you
want to see this latest parser, you can find it under the tads 3 download
links at the tads.org site.)

The steps involved in writing your own parser are pretty straightforward.
First, you break up the input text into tokens. You have to make certain
decisions about what counts as a token, but that's easy; for example, if you
see an apostrophe, it's part of a contraction, so it goes with the word,
unless it's an "apostrophe s", in which case it's a possessive so it counts
as a separate token, or if it's used to "single-quote" an embedded string.
Second, you match the tokens to the grammar. This is also easy, because
English and other natural languages have small grammars that boil down to a
few simple rules, such as: the verb comes first, except when it's a command
to another character (in which case the other character's name comes first).
A verb is just an "action word," or an action word and a preposition ("pick
up"), but fortunately the preposition is easiest to handle because it can go
in several different places, such as just after the verb ("pick up box") or
after the object ("pick it up"). The only hard part is that you don't know
whether or not you're parsing a command to another character until you parse
the sentence, but to parse the sentence you need to know which rule to use,
but to know which rule to use you have to parse the sentence, etc.; so it's
a bit of a catch-22, but most programming languages these days have the
"intuition" function that nicely glosses over this detail. The "intuition"
feature is especially helpful when the same word can be used in several
different ways, as in "plant supervisor, plant plant, plant food, and plant
growth medium in plant box." Commas are also a good thing to defer to
intuition, because they serve so many purposes (introducing the verb after
the target character, separating noun phrases in a list, separating verb
phrases). Third, now that you know the grammar, you just extract the
meaning of the sentence and do what it says. The "meaning" is just a
C-style structure that you fill in with the appropriate fields: character,
actor, verb, direct object (of course, this might actually be an array),
indirect object (which also might be an array). One thing that can be a bit
tricky is picking out the simulation object to which a particular noun
phrase refers; game authors have this incredibly inconsiderate habit of
using the same nouns and adjectives over and over to refer to *different*
objects, if you can even believe it - and the really irritating thing is
that they insist that adding lots of vocabulary words to their objects is
actually a good thing! Whatever.

So, that's basically it. My own experience is that you can get a lot of
this simple stuff going pretty quickly, but it's amazing how long it takes
to iron out all the little details. But it's certainly not difficult, so if
you have a couple of years, definitely go for it.

--Mike
mjr underscore at hotmail dot com

Fredrik Ramsberg

unread,
Jan 29, 2003, 3:17:56 PM1/29/03
to
junkaccou...@yahoo.com (Benjamin Fan) wrote in message news:<9ea00d5e.03012...@posting.google.com>...

> I can understand why writing a "great" parser might be
> difficult, but a pretty good one seems to be easy enough.

Nice job with the Java parser!

What Neil said is true -- it takes a little more work to translate these
grammatical constructs into actor, action, primary and secondary object in
the game world. Still, I think what you said is also true -- it's not
extremely difficult to write a parser that is pretty good. I think the two
biggest reasons why I won't write any more IF games in general purpose
languages are:

1. The fact that Inform has great support for the kind of object declarations
that are needed all the time in IF -- loads of unique objects whose
properties are known at compile time. I can also easily mix numbers, strings
and routines/functions in object properties. The fact that it has a convenient
class mechanism that suits the typical IF writing needs very well is also
important.

2. The library and its world model. Their existence mean I have a rather
complete and complex model of how the world works implemented even before I've
start coding myself.

The fact that these things make life easier for me gives me more time and
energy to concentrate both on the story and the more high-level coding needed
for that. I really can't see why I'd want to write an IF game in a less
suitable language, unless it's just for the exercise or challenge.

/Fredrik

Neil Cerutti

unread,
Jan 29, 2003, 3:22:31 PM1/29/03
to
In article <9ea00d5e.0301...@posting.google.com>,
Benjamin Fan wrote:

> Neil Cerutti <cer...@trans-video.net> wrote:
> I think that there is confusion over definitions. By "parser",
> I mean the part that takes player input and applies grammar
> rules to separate the input into different parts of speech.
> That is all the parser is supposed to do.
>
> The other tasks you mention include taking the output from the
> parser, recognizing whether it is valid for the game (if not,
> printing error messages or prompting for additional
> information), and other tasks related to processing game
> commands and changing game state. I call this the Command
> Handler, and I consider it to be part of the game engine,
> separate from the parser.
>
>> "drop all but lamp and sword"
>
> Do players use this "all but" construct that often?

It's not nearly as necessary in modern games, which tend to
mollycoddle players, but I find it indispensable and common in
any game that imposes an inventory limit. But even in a game with
no inventory limit, it's lack would make a parser look
amateurish and recalcitrant.

> I agree that writing a sophisticated Command Handler is a more
> difficult task, but it does not seem terribly difficult either.
> Perhaps when people talk about the the "parser", they actually
> mean the combined parser/command_handler/game_engine.

What I mean when I say "parser", is a program that reads input,
disambiguates (makes assumptions if possible, seeks clarification
otherwise) and emits commands to the game engine or error
messages to the player. I don't speak for raif, though. ;-)

--
Neil Cerutti <cer...@trans-video.net>

Nikos Chantziaras

unread,
Jan 29, 2003, 4:00:52 PM1/29/03
to
Benjamin Fan wrote:
> Neil Cerutti <cer...@trans-video.net> wrote:
> > A parser must be aware of the game state, otherwise it cannot
> > make correct assumptions, or ask intelligent questions. A parser
> > generates lists of actions for the world model to carry out, not
> > a mere breakdown into grammatical sections. At best you've
> > written a limited front-end to a real parser. A lot of the
> > complexity, as in a compiler, will be in the back-end.
>
> I think that there is confusion over definitions. By "parser",
> I mean the part that takes player input and applies grammar rules to
> separate the input into different parts of speech. That is all the
> parser is supposed to do.

I thought that this is the job of the lexical analyzer, not the parser. I
may be wrong though.


-- Niko


Nikos Chantziaras

unread,
Jan 29, 2003, 4:13:32 PM1/29/03
to
Mike Roberts wrote
> [...]

> So, that's basically it. My own experience is that you can get a lot
> of this simple stuff going pretty quickly, but it's amazing how long
> it takes to iron out all the little details. But it's certainly not
> difficult, so if you have a couple of years, definitely go for it.
> ^^^^^^^^^^^^^^^

*LOL*


-- Niko


Charlton Wilbur

unread,
Jan 29, 2003, 5:45:16 PM1/29/03
to
>>>>> "MR" == Mike Roberts <mjrUND...@hotmail.com> writes:

MR> It should be obvious to everyone that parsing is extremely
MR> easy. If it were so hard, how could literally thousands of
MR> humans do it effortlessly every day in ordinary conversation?
MR> Do we have to go to "parsing school" in order to talk to each
MR> other? Of course not! It comes naturally enough to most of
MR> us; the only people who have a lot of trouble with it seem to
MR> be those elected to high political office. Programming a
MR> parser should just be a simple matter of rewriting this
MR> everyday knowledge into C++ or the language of your choice.

How wonderfully naive.

We *do*, in fact, go to parsing school. It's called language
acquisition, and it's a hard problem; much ink has been spilled on
ways of getting computers to do it correctly.[1]

Consider the following sentence:

Time flies like an arrow; fruit flies like a banana.

This makes most people laugh, because of the ambiguity in it.
Generally, in the first clause humans understand 'time' as the
subject and 'flies' as the verb, while in the second clause humans
understand 'fruit flies' as the subject and 'like' as the verb. But
the disambiguation comes from information outside the sentence:
specifically, that there are things called 'fruit flies' and no
corresponding things called 'time flies.'

Now, most fluent speakers of English can parse that sentence, and
identify the parts of speech in it. (Given today's educational
standards, they might need to be introduced to terms such as 'subject'
and 'verb,' but that's secondary.) Many of them can even identify the
ambiguity that allows each clause to be read two ways. *That* is an
example of why parsing is difficult.

Even given a restricted vocabulary and grammar, such as that employed
by most interactive fiction: consider a word like 'light.' It might
be a noun, or it might be a verb, or it might be an adjective. How do
you figure out which one is meant? This is not "everyday knowledge,"
because human brains don't operate the same way that computers do.

Charlton


[1] Millions of humans also walk effortlessly and recognize other
people effortlessly; both of these are difficult problems for
computers as well. By Mr Roberts's theory, writing a program to
recognize pictures of your mother should be easy -- since it comes
naturally, it should just be a simple matter of rewriting the everyday
knowledge of how you recognize your mother into C++ or the language of
your choice!

Magnus Olsson

unread,
Jan 29, 2003, 6:13:15 PM1/29/03
to
In article <b19fei$10rs5n$1...@ID-151409.news.dfncis.de>,

Nikos Chantziaras <for....@manager.de> wrote:
>Benjamin Fan wrote:
>> Neil Cerutti <cer...@trans-video.net> wrote:
>> > A parser must be aware of the game state, otherwise it cannot
>> > make correct assumptions, or ask intelligent questions. A parser
>> > generates lists of actions for the world model to carry out, not
>> > a mere breakdown into grammatical sections. At best you've
>> > written a limited front-end to a real parser. A lot of the
>> > complexity, as in a compiler, will be in the back-end.
>>
>> I think that there is confusion over definitions.

Yes, there is. "Parser" means something more when we're talking about
IF than it usually does.

>>By "parser",
>> I mean the part that takes player input and applies grammar rules to
>> separate the input into different parts of speech. That is all the
>> parser is supposed to do.
>
>I thought that this is the job of the lexical analyzer, not the parser.

No, the lexical analyzer breaks the input sentence up into tokens, or
lexemes - usually individual words and punctuation marks. It doesn't
know anything about grammar, nor does it care.

--
Magnus Olsson (m...@df.lth.se)
PGP Public Key available at http://www.df.lth.se/~mol

John W. Kennedy

unread,
Jan 29, 2003, 8:14:08 PM1/29/03
to

That might be the job of a compiler lexer, but, in natural languages,
about all the lexer can do is get the words and the punctuation. Too
many words (especially in English) cannot identified as to part of
speech until the sentence is parsed, while the sentence cannot be parsed
until the words are identified as to parts of speech, and neither can be
done without knowledge-based disambiguation.

Time flies like an arrow.
Fruit flies like a banana.
Count flies like an entomologist.

It's a pretty little girls' school.

In the normal jargon of the IF world, a "parser" identifies parts of
speech, performs grammatical analysis of the sentence, and disambiguates
with knowledge of the current state of the game world. It's regarded as
a single component because it is, of necessity, a single process.

--
John W. Kennedy
"The poor have sometimes objected to being governed badly;
the rich have always objected to being governed at all."
-- G. K. Chesterton, "The Man Who Was Thursday"

Shadow Wolf

unread,
Jan 29, 2003, 7:18:23 PM1/29/03
to
Charlton Wilbur <cwi...@mithril.chromatico.net> wrote in
news:874r7r3...@mithril.chromatico.net:

>>>>>> "MR" == Mike Roberts <mjrUND...@hotmail.com> writes:
>
> MR> It should be obvious to everyone that parsing is extremely
> MR> easy. If it were so hard, how could literally thousands of
> MR> humans do it effortlessly every day in ordinary conversation?
> MR> Do we have to go to "parsing school" in order to talk to each
> MR> other? Of course not! It comes naturally enough to most of
> MR> us; the only people who have a lot of trouble with it seem to
> MR> be those elected to high political office. Programming a
> MR> parser should just be a simple matter of rewriting this
> MR> everyday knowledge into C++ or the language of your choice.
>
> How wonderfully naive.

Please note that Roberts is being _extremely_ tongue-in-cheek here. He does
indeed know what goes into making a parser -- he is, after all the author
of both TADS2 and TADS3.

Note the rest of his post, which talks about using the "intuition" function
of "modern programming languages", among other tongue-in-cheek remarks.

>
> We *do*, in fact, go to parsing school. It's called language
> acquisition, and it's a hard problem; much ink has been spilled on
> ways of getting computers to do it correctly.[1]
>
>

> [1] Millions of humans also walk effortlessly and recognize other
> people effortlessly; both of these are difficult problems for
> computers as well. By Mr Roberts's theory, writing a program to
> recognize pictures of your mother should be easy -- since it comes
> naturally, it should just be a simple matter of rewriting the everyday
> knowledge of how you recognize your mother into C++ or the language of
> your choice!
>

--
Shadow Wolf
shado...@softhome.net
Stories at http://www.asstr.org/~Shadow_Wolf

jibi

unread,
Jan 30, 2003, 7:21:08 AM1/30/03
to
>
> Consider the following sentence:
>
> Time flies like an arrow; fruit flies like a banana.
>
[...]

>
> Now, most fluent speakers of English can parse that sentence, and
> identify the parts of speech in it.

Being non-native english speaker, it took me some time to understand
why this fruit would fly like a banana.
But actually if a fruit would fly, banana would be a good choice since
it has something with aerodynamics.

JB

Ally

unread,
Jan 30, 2003, 7:59:14 AM1/30/03
to
ji...@le-kaki.com (jibi) wrote:
> Being non-native english speaker, it took me some time to understand
> why this fruit would fly like a banana.
> But actually if a fruit would fly, banana would be a good choice since
> it has something with aerodynamics.
>
> JB
>

I've always parsed it that way myself, and was baffled for a moment when I
first "got" it. I've been assuming it was supposed to point out the
absurdity of the notion that time "flies" by contrasting it with the way
something as un-abstract as (a) fruit would fly. Something like that
anyway.

~Ally

Mark J. Tilford

unread,
Jan 30, 2003, 8:10:27 AM1/30/03
to

You're misinterpreting the sentence. The intended meaning is similar to that
of "A fruit fly likes a banana."

--
------------------------
Mark Jeffrey Tilford
til...@ugcs.caltech.edu

Mark 'Kamikaze' Hughes

unread,
Jan 30, 2003, 8:52:27 AM1/30/03
to
Thu, 30 Jan 2003 13:59:14 +0100, Ally <kitzapoo_R...@gmx.co.uk>:

> ji...@le-kaki.com (jibi) wrote:
>> Being non-native english speaker, it took me some time to understand
>> why this fruit would fly like a banana.
>> But actually if a fruit would fly, banana would be a good choice since
>> it has something with aerodynamics.
> I've always parsed it that way myself, and was baffled for a moment when I
> first "got" it. I've been assuming it was supposed to point out the
> absurdity of the notion that time "flies" by contrasting it with the way
> something as un-abstract as (a) fruit would fly. Something like that
> anyway.

Heh. This is exactly why real natural-language parsing is insanely
hard. You lack one vital piece of information: there is an insect
called a "fruit fly".

Time (noun, the stuff that keeps everything from happening at once)
flies (verb, moves forward) like (preposition, similar to) an arrow
(noun, pointy thing that kills people).

Fruit flies (noun, the insects) like (verb, appreciate) a banana
(noun, or any other fruit, that's why they're called "fruit flies").

Now, in reality, text adventures don't need natural-language parsing.
You can do a lot with really stupid parsing tricks, and the players
won't even usually notice, or care even if they do.

--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"We remain convinced that this is the best defensive posture to adopt in
order to minimize casualties when the Great Old Ones return from beyond
the stars to eat our brains." -Charlie Stross, _The Concrete Jungle_

Neil Cerutti

unread,
Jan 30, 2003, 9:01:57 AM1/30/03
to
In article <slrnb3ibgr.2...@kuoi.asui.uidaho.edu>, Mark

'Kamikaze' Hughes wrote:
> Thu, 30 Jan 2003 13:59:14 +0100, Ally <kitzapoo_R...@gmx.co.uk>:
>> ji...@le-kaki.com (jibi) wrote:
>> I've always parsed it that way myself, and was baffled for a
>> moment when I first "got" it. I've been assuming it was
>> supposed to point out the absurdity of the notion that time
>> "flies" by contrasting it with the way something as
>> un-abstract as (a) fruit would fly. Something like that
>> anyway.
>
> Heh. This is exactly why real natural-language parsing is
> insanely hard. You lack one vital piece of information: there
> is an insect called a "fruit fly".
>
> Time (noun, the stuff that keeps everything from happening at
> once) flies (verb, moves forward) like (preposition, similar
> to) an arrow (noun, pointy thing that kills people).
>
> Fruit flies (noun, the insects) like (verb, appreciate) a
> banana (noun, or any other fruit, that's why they're called
> "fruit flies").

I think the example cheats to preserve it's symmetry. To me, it
should be:

"Time flies like an arrow; fruit flies like bananas."

The urtext phrasing makes it sounds like all fruit flies like one
banana of all possible bananas.

--
Neil Cerutti <cer...@trans-video.net>

Mark 'Kamikaze' Hughes

unread,
Jan 30, 2003, 9:07:51 AM1/30/03
to
30 Jan 2003 14:01:57 GMT, Neil Cerutti <cer...@trans-video.net>:

Not at all. "Mark likes a good book." It's using a single object as
an example. Perfectly legitimate and common English grammar.

Neil Cerutti

unread,
Jan 30, 2003, 9:52:42 AM1/30/03
to
In article <slrnb3icd0.2...@kuoi.asui.uidaho.edu>, Mark 'Kamikaze' Hughes wrote:
> 30 Jan 2003 14:01:57 GMT, Neil Cerutti <cer...@trans-video.net>:
>> In article <slrnb3ibgr.2...@kuoi.asui.uidaho.edu>, Mark
>> 'Kamikaze' Hughes wrote:
>>> Heh. This is exactly why real natural-language parsing is
>>> insanely hard. You lack one vital piece of information: there
>>> is an insect called a "fruit fly".
>>> Time (noun, the stuff that keeps everything from happening at
>>> once) flies (verb, moves forward) like (preposition, similar
>>> to) an arrow (noun, pointy thing that kills people).
>>> Fruit flies (noun, the insects) like (verb, appreciate) a
>>> banana (noun, or any other fruit, that's why they're called
>>> "fruit flies").
>> I think the example cheats to preserve it's symmetry. To me, it
>> should be:
>> "Time flies like an arrow; fruit flies like bananas."
>> The urtext phrasing makes it sounds like all fruit flies like one
>> banana of all possible bananas.
>
> Not at all. "Mark likes a good book." It's using a single
> object as an example. Perfectly legitimate and common English
> grammar.

I agree, it's legimate and common. But I prefer "Mark likes good
books."

--
Neil Cerutti <cer...@trans-video.net>

Dan Schmidt

unread,
Jan 30, 2003, 10:59:12 AM1/30/03
to
Charlton Wilbur <cwi...@mithril.chromatico.net> writes:

| >>>>> "MR" == Mike Roberts <mjrUND...@hotmail.com> writes:
|
| MR> It should be obvious to everyone that parsing is extremely
| MR> easy. If it were so hard, how could literally thousands of
| MR> humans do it effortlessly every day in ordinary conversation?
| MR> Do we have to go to "parsing school" in order to talk to each
| MR> other? Of course not! It comes naturally enough to most of
| MR> us; the only people who have a lot of trouble with it seem to
| MR> be those elected to high political office. Programming a
| MR> parser should just be a simple matter of rewriting this
| MR> everyday knowledge into C++ or the language of your choice.
|
| How wonderfully naive.

He was making a joke.

Dan

--
http://www.dfan.org

atholbrose

unread,
Jan 30, 2003, 4:13:45 PM1/30/03
to
Neil Cerutti <cer...@trans-video.net> wrote in news:b1bb8k$110mp3$1@ID-
60390.news.dfncis.de:

> I think the example cheats to preserve it's symmetry. To me, it
> should be:
> "Time flies like an arrow; fruit flies like bananas."

Well, you go take it up with Groucho Marx, then.

--
r. n. dominick / ur...@bookmice.net
mini-if site: http://www.bookmice.net/coffeehouse/

Neil Cerutti

unread,
Jan 30, 2003, 4:11:11 PM1/30/03
to
In article <Xns9313A3E51622...@65.24.2.12>, atholbrose wrote:
> Neil Cerutti <cer...@trans-video.net> wrote in news:b1bb8k$110mp3$1@ID-
> 60390.news.dfncis.de:
>
>> I think the example cheats to preserve it's symmetry. To me,
>> it should be: "Time flies like an arrow; fruit flies like
>> bananas."
>
> Well, you go take it up with Groucho Marx, then.

Groucho Marx likes a joke.

--
Neil Cerutti <cer...@trans-video.net>

Greg Ewing (using news.cis.dfn.de)

unread,
Jan 30, 2003, 8:30:55 PM1/30/03
to
Neil Cerutti wrote:

> I agree, it's legimate and common. But I prefer "Mark likes good
> books."


But, to a native English speaker, that doesn't have quite
the same connotation.

I'm trying to think of a way of explaining the difference,
but it's not easy. Let's see...

If you say "Mark likes a good book" you're saying something
about what Mark habitually enjoys doing for relaxation.

But if you say "Mark likes good books" you're saying something
about Mark's value judgement concerning books.

Does that make any sense?

--
Greg

Mark 'Kamikaze' Hughes

unread,
Jan 31, 2003, 2:40:09 AM1/31/03
to
Fri, 31 Jan 2003 14:30:55 +1300, Greg Ewing (using news.cis.dfn.de)
<m...@privacy.net>:

It does to me, I just couldn't think of the right way to express that.
I can't find the rule in my grammar handbook, but there is a
distinction.

Yes, English can be that picky and subtle. Again, this is a perfect
demonstration of how hard natural-language parsing would be. I expect
that to do NLP right, we'll need true artificial intelligence, but
keeping a sentient being prisoner just to do your parsing is slavery.
The problem can never be solved.

jibi

unread,
Jan 31, 2003, 4:21:20 AM1/31/03
to
Believe it or not, but I actually understood the joke and was ironic
;-)

But this made me think of a good solution to remove the ambiguity :
because if you tell the sentence in english, there would be
accentuation that would made you understand which is which.

In french we don't have any accentuation at all, and playing with
words in order to forge semantic ambiguity (for fun, or...as a
professional trick. Did you know that french is the language of the
diplomacy?) and you can sometimes be really puzzled.
We even have what we call "Holorimes", it is poems which all the
verses sounds the same, but doesn't write or means the same.

"Gal, amant de la Reine, alla, tour magnanime,
galammant de l'arčne ą la Tours Magnes, ą Nīmes. "

(Gal, the Queen's lover, went, magnificient trick,
leaving the arena for the Tower Magnes, in Nimes.)

So the solution is simple : parsing the words and the scansion. Latin
readers would have though to that, I guess, since they used scansion
to interpret cryptic texts.

JB


"Mark J. Tilford" <til...@ugcs.caltech.edu> wrote in message news:<slrnb3i8ne....@ralph.earthlink.net>...

John W. Kennedy

unread,
Jan 31, 2003, 9:53:49 AM1/31/03
to
jibi wrote:
> Believe it or not, but I actually understood the joke and was ironic
> ;-)
>
> But this made me think of a good solution to remove the ambiguity :
> because if you tell the sentence in english, there would be
> accentuation that would made you understand which is which.
>
> In french we don't have any accentuation at all, and playing with
> words in order to forge semantic ambiguity (for fun, or...as a
> professional trick. Did you know that french is the language of the
> diplomacy?) and you can sometimes be really puzzled.
> We even have what we call "Holorimes", it is poems which all the
> verses sounds the same, but doesn't write or means the same.
>
> "Gal, amant de la Reine, alla, tour magnanime,
> galammant de l'arčne ą la Tours Magnes, ą Nīmes. "
>
> (Gal, the Queen's lover, went, magnificient trick,
> leaving the arena for the Tower Magnes, in Nimes.)
>
> So the solution is simple : parsing the words and the scansion. Latin
> readers would have though to that, I guess, since they used scansion
> to interpret cryptic texts.

Such devices are occasionally used in English light verse, always in
forms such as triolets, ballades, etc., that English derived from French.

Michael Laurino

unread,
Jan 31, 2003, 5:10:22 PM1/31/03
to
On 31 Jan 2003 01:21:20 -0800, ji...@le-kaki.com (jibi) wrote:

>professional trick. Did you know that french is the language of the
>diplomacy?)

Which explains why there's always a war or two going on somewhere...

HC

unread,
Feb 1, 2003, 4:56:51 AM2/1/03
to

"jibi" <ji...@le-kaki.com> wrote in message
news:32b1e61d.03013...@posting.google.com...

> Believe it or not, but I actually understood the joke and was ironic
> ;-)
>
> But this made me think of a good solution to remove the ambiguity :
> because if you tell the sentence in english, there would be
> accentuation that would made you understand which is which.

Unless you're Groucho Marx, who says everything in such a strange voice that
you can't really pick out the meaning. At least in this case.

HC

Adam Thornton

unread,
Jan 31, 2003, 10:56:29 AM1/31/03
to
In article <32b1e61d.03013...@posting.google.com>,

jibi <ji...@le-kaki.com> wrote:
>So the solution is simple : parsing the words and the scansion. Latin
>readers would have though to that, I guess, since they used scansion
>to interpret cryptic texts.

Just to make it crystal clear: I'm *not* implementing elisions, either
for input or output, in version 1 of Latin.h.

However, if someone gets me full Unicode support in the terps, I will do
diacritics.

Adam

Adam Thornton

unread,
Jan 29, 2003, 3:20:31 PM1/29/03
to
In article <XjWZ9.13$v47...@news.oracle.com>,
Mike Roberts <mjrUND...@hotmail.com> wrote:
>> "Benjamin Fan" <junkaccou...@yahoo.com> wrote:
>> Why are IF input parsers considered to be difficult to
>> implement?
>"Neil Cerutti" <cer...@trans-video.net> replied:

>> A parser must be aware of the game state, otherwise it cannot
>> make correct assumptions, or ask intelligent questions. [...]

>> A lot of the complexity, as in a compiler, will be in the
>> back-end.
>"Andrew Plotkin" <erky...@eblong.com> replied:
>> Extensibility.
>"Kent Tessman" <ke...@remove-to-reply.generalcoffee.com>:
>> The tough part is the integration of the parser with the
>> management of the game world, which means having the
>> functionality of the parser be responsive to the game state.

>This is all just propaganda! Don't listen to them! They're just trying to
>protect their precious monopolies on parsing.

[...snip...]

You, sir, are my hero.

Adam

Richard Bos

unread,
Feb 3, 2003, 9:43:08 AM2/3/03
to
ad...@fsf.net (Adam Thornton) wrote:

There are no diacritics in real Latin, and I prefer to read it without
them. Yes, even verse.

Richard

Adam Thornton

unread,
Feb 3, 2003, 11:49:16 AM2/3/03
to
In article <3e3e7fda....@news.nl.net>,

Richard Bos <r...@hoekstra-uitgeverij.nl> wrote:
>There are no diacritics in real Latin, and I prefer to read it without
>them. Yes, even verse.

You are clearly studlier than I am. I don't suppose you'd care to write
Latin.h, so I can get on to the exciting parts of _Mentula Macanus:
Apocolocyntosis_ ?

Adam

LizM7

unread,
Feb 3, 2003, 3:25:07 PM2/3/03
to
junkaccou...@yahoo.com (Benjamin Fan) wrote:
> Neil Cerutti <cer...@trans-video.net> wrote:
> > "drop all but lamp and sword"
>
> Do players use this "all but" construct that often?

*I* do. Especially if you have a game where, say, you have an object
which will shatter if you drop it.

- Liz

Richard Bos

unread,
Feb 4, 2003, 4:31:40 AM2/4/03
to
ad...@fsf.net (Adam Thornton) wrote:

> In article <3e3e7fda....@news.nl.net>,
> Richard Bos <r...@hoekstra-uitgeverij.nl> wrote:
> >There are no diacritics in real Latin, and I prefer to read it without
> >them. Yes, even verse.
>
> You are clearly studlier than I am.

That could be disputed. You have written several well-known works of IF,
while all I have to show for my efforts are two mini-comp entries.

> I don't suppose you'd care to write
> Latin.h, so I can get on to the exciting parts of _Mentula Macanus:
> Apocolocyntosis_ ?

Erm... no. I may be able to read Latin (provided it isn't too literary
or philosophical), but when I try to write it I have to bluff around my
ignorance. The only reason I prefer not to have diacritics is that they
interfere with my mind's attempts to read the metre itself (and that is,
at least in part, a result of practicing the same habit when reading
Chaucer).

Richard

0 new messages