QuickBasic 4.5 and Parsers
Jack Poteet
I've saw parsers written in older Basic in games like Miser, but they are very
hard to follow. All those goto's make it very good spaghetti code. Any docs
or newsletters would help.
Jesse McGrew
Jack Poteet (jpo...@compunet.net) wrote in article
<jpoteet.4...@compunet.net>:
: Is there anyone that could help or guide me on writing a parser in QuickBASIC.
: hard to follow. All those goto's make it very good spaghetti code. Any docs
: or newsletters would help.
Are you trying to write a text game in Basic? That's quite an undertaking
if you want a decent parser (one that can handle "bob, find jones. tell
him to drive the car to my house, take all of the red boxes and two of the
green ones, and bring it to me" correctly).
--
I am kow. Worship me.
Alex Oren
: Are you trying to write a text game in Basic? That's quite an undertaking
: if you want a decent parser (one that can handle "bob, find jones. tell
: him to drive the car to my house, take all of the red boxes and two of the
: green ones, and bring it to me" correctly).
Is there a sample source (in C or any other "mainstream" language) of a
parset that's capable of such feats?
Have fun,
Alex
Judson Lester
av...@netvision.net.il (Alex Oren) wrote:
Unless you have weird purposes for writing in BASIC, I'd suggest using
Inform, which, if you can program on a basic level, you can deal with
Inform, which not only provides a very sophisticated parser but also can
have it's parser messed around with. It's incredibly nice to code in.
Cheers,
Judson
FReDRiK RaMSBeRG (WILdcARD)
>jes...@comtch.iea.com (Jesse McGrew) wrote:
>: Are you trying to write a text game in Basic? That's quite an undertaking
>: if you want a decent parser (one that can handle "bob, find jones. tell
>: him to drive the car to my house, take all of the red boxes and two of the
>: green ones, and bring it to me" correctly).
This kind of answers can only help to discourage people from writing
IF stories. I presume this wasn't your intention.
Anyway, what is correct here? The sentence is ambigous. No human could be
certain about whether it's Bob or Jones who is supposed to bring you the
boxes, so how do you expect the game to be?
>Is there a sample source (in C or any other "mainstream" language) of a
>parset that's capable of such feats?
No matter what, the stuff described above rules out _at least_ 98% of the
parsers used in shareware games today, and something like 90% of the Infocom
parsers. Let's suppose Quickbasic is, overall, the best system available to
the author, on that platform, and make the best of it; A parser that handles
the following will be no big problem to anyone skilled in BASIC;
bob, go to the cabin and tell jones to drive the car to my house
get all
put the small green key on the table
I'd say that this level of parser will never feel like a constraint either
when designing or playing the game. It's better to put the effort into the
story than making a super-mega-parser that will at least _try_ to evaluate
sentences so complicated that no one ever types them.
Let's not forget that the goal of making IF stories is to amuse the player,
not to provide pornography for Natural Language Parsing enthusiasts. (Or did
I get it all wrong?)
Let the IF tradition live,
/Fredrik Ramsberg
--
-----------------------------------------------------------------------------
Fredrik Ramsberg, student at Linkoeping University
Hi-tech-mail: d91f...@und.ida.liu.se
-----------------------------------------------------------------------------
Magnus Olsson
FReDRiK RaMSBeRG (WILdcARD) <d91f...@ida.liu.se> wrote:
>av...@netvision.net.il (Alex Oren) writes:
>
>>jes...@comtch.iea.com (Jesse McGrew) wrote:
>
>>: Are you trying to write a text game in Basic? That's quite an undertaking
>>: if you want a decent parser (one that can handle "bob, find jones. tell
>>: him to drive the car to my house, take all of the red boxes and two of the
>>: green ones, and bring it to me" correctly).
>
>This kind of answers can only help to discourage people from writing
>IF stories. I presume this wasn't your intention.
I think his intention was to discourage people from writing IF stories
in QuickBasic.
Personally, I wouldn't dream of discouraging people from writing IF,
or from trying to implement natural-language interfaces to other
programs. However, I do think we "veterans" are actually doing people
a favour by pointing out that they really ought to use good tools. To
use an analogy, I think it's good that people try building their own
hardware (even though it's getting increasingly difficult these days),
however, I would discourage them from mounting IC's with an old
kerosene-heated soldering iron intended for mending coffee pots.
QuickBasic is an excellent language in many ways (at least compared to
other Basics), but writing parsers in QB is simply a lot more work
than writing them in, say, Bison (which is free, BTW). Writing IF in
QB is even more work compared to doing it in Inform or Alan (both of
which are free, BTW). Trust me, I've written IF both from scratch (in
Pascal, which is still a better language for the task than even a
modern, structured Basic like QB) and in Inform and TADS and I know
exactly what's involved. I've written recursive-descent parsers in
Modula 2 (and that was for context-free languages - a much simpler
problem than English) and I've written parser actions in Inform. Need
I tell you which I prefer?
> Let's suppose Quickbasic is, overall, the best system available to
>the author, on that platform, and make the best of it; A parser that handles
>the following will be no big problem to anyone skilled in BASIC;
>
>bob, go to the cabin and tell jones to drive the car to my house
>get all
>put the small green key on the table
>
>I'd say that this level of parser will never feel like a constraint either
>when designing or playing the game.
Have you ever written a parser that could handle that kind of sentences?
Have you written the code to handle the necessary disambiguation for the
parser to be useable in an adventure game? Did you write it in Basic?
If not, then I suggest you try the task. If you have, then you should
know better than saying that it should be "no big problem". The Basic
coding is the small part of it; the big part is constructing the
grammar, the parser tables, and so on, and this is just for the
parser. The disambiguation is quite a non-trivial problem, too.
I'm not trying to discourage anyone from doing anything. I'm just
trying to *encourage* people to use the proper tools for the task,
rather than trying to hammer in screws or using a screwdriver to drive
in nails.
>Let's not forget that the goal of making IF stories is to amuse the player,
>not to provide pornography for Natural Language Parsing enthusiasts. (Or did
>I get it all wrong?)
You didn't get it all wrong, but you missed one essential step: for a
game to be enjoyable, the parser must be quite capable. The AGT parser
is probably quite complex and capable (i haven't seen the source, so I
can't tell how complex), the Advsys parser certainly is, yet neither
of those are seen to be quite good enough by game reviewers.
Magnus Olsson (m...@df.lth.se)
Julian Arnold
> >: Are you trying to write a text game in Basic? That's quite an undertaking
> >: if you want a decent parser (one that can handle "bob, find jones. tell
> >: him to drive the car to my house, take all of the red boxes and two of the
> >: green ones, and bring it to me" correctly).
>
> This kind of answers can only help to discourage people from writing
> IF stories. I presume this wasn't your intention.
I think you're confused between IF *stories* and IF *authoring systems*. In
any case, I understood the answer not as one to discourage people from
writing IF, but rather as one to discourage people from making it
unnecessarily hard for themselves.
If you're just interested in writing an IF story, there are already a great
number of very worthwhile authoring systems available for probably every
reasonable computer. There's no particular need to go to the trouble of
re-inventing the wheel.
If, however, you do want to write such a system yourself, even if it's only a
programming exercise, you're probably better off not using BASIC.
Also, a BASIC IF story is going to be fairly platform-specific. The beauty
of the readily available authoring systems is that the storyfiles they
produce are, by and large, platform independent.
> It's better to put the effort into the story than making a
> super-mega-parser that will at least _try_ to evaluate sentences so
> complicated that no one ever types them.
Well, in that case, why not use an authoring system where the parser has
already been developed for you?
> Let's not forget that the goal of making IF stories is to amuse the player,
> not to provide pornography for Natural Language Parsing enthusiasts. (Or did
> I get it all wrong?)
What? Most players will quickly become unamused if your parser cannot handle
a reasonable input. No parsers I have seen are capable of real NLP, but this
is not generally necessary (it would help immensely for player-NPC
conversation though).
(That said, I do think the "bob..." example was a leetle OTT).
Jools
Jesse McGrew
FReDRiK RaMSBeRG (WILdcARD) (d91f...@ida.liu.se) wrote in article
<d91frera.824159921@news>:
[unbelievable parser exercise]
[snip]
: Anyway, what is correct here? The sentence is ambigous. No human could be
: certain about whether it's Bob or Jones who is supposed to bring you the
: boxes, so how do you expect the game to be?
> bob, find jones. tell him to drive the car to my house, take all of the
red boxes and two of the green ones, and bring them to me
^^^^
(incorrect in my original post)
Periods would take precedence over commas, so the following actions would
be given:
bob, find jones
jones, drive the car to my house
jones, take all of the red boxes and two of the green ones
jones, bring them to me
If "them" were "it" (as in my original post), "it" would refer to the car.
I hope to have a parser this powerful in Snack, but don't bet your life on
it.
--
AlloyMUSH! http://www.iea.com/~jessem/mush
AlloyMUSH 1.1, AlloyNet, and Snack are coming. Watch this space.
Fredrik Ramsberg
>In article <d91frera.824159921@news>,
>FReDRiK RaMSBeRG (WILdcARD) <d91f...@ida.liu.se> wrote:
>>av...@netvision.net.il (Alex Oren) writes:
>>>jes...@comtch.iea.com (Jesse McGrew) wrote:
>>
>>>: Are you trying to write a text game in Basic? That's quite an undertaking
>>>: if you want a decent parser (one that can handle "bob, find jones. tell
>>>: him to drive the car to my house, take all of the red boxes and two of the
>>>: green ones, and bring it to me" correctly).
>>
>>This kind of answers can only help to discourage people from writing
>>IF stories. I presume this wasn't your intention.
>I think his intention was to discourage people from writing IF stories
>in QuickBasic.
That's probably so, and the replies to my article has given me another way
of interpreting the answer I was commenting.
However, I'm not sure everybody does that interpretation, and I still think
this kind of answers may give newbies the impression that if they can't write
a parser this good, they'd better stay off the scene all together. If you want
to discourage people from writing in QuickBasic, hand them alternatives
instead of just non-constructive criticism of their approach.
>Personally, I wouldn't dream of discouraging people from writing IF,
>or from trying to implement natural-language interfaces to other
>programs. However, I do think we "veterans" are actually doing people
>a favour by pointing out that they really ought to use good tools.
Good point. However, I don't think the article pointed that out very clearly.
>> Let's suppose Quickbasic is, overall, the best system available to
>>the author, on that platform, and make the best of it; A parser that handles
>>the following will be no big problem to anyone skilled in BASIC;
>>
>>bob, go to the cabin and tell jones to drive the car to my house
>>get all
>>put the small green key on the table
>>
>>I'd say that this level of parser will never feel like a constraint either
>>when designing or playing the game.
>Have you ever written a parser that could handle that kind of sentences?
>Have you written the code to handle the necessary disambiguation for the
>parser to be useable in an adventure game? Did you write it in Basic?
I've done it in C64-BASIC, Lisp, Rabies and AM (The last two being homemade
IF languages).
>If not, then I suggest you try the task. If you have, then you should
>know better than saying that it should be "no big problem". The Basic
>coding is the small part of it; the big part is constructing the
>grammar, the parser tables, and so on, and this is just for the
>parser. The disambiguation is quite a non-trivial problem, too.
When writing in BASIC, there is not support for the same level of abstraction
that you use in say TADS or Inform, or Lisp for that matter. Thus, much of the
grammar and parser tables must be a part of the parser code. This is never an
extremely good looking solution, and it does have it's limitations, but if you
are to develop both the parser and the rest of the game yourself and the level
of parser mentioned above will do, then it is actually, as I said before, no
big problem to implement it. If anyone is interested, I'll post the algorithm
(with implicit grammar etc) for such a parser.
>>Let's not forget that the goal of making IF stories is to amuse the player,
>>not to provide pornography for Natural Language Parsing enthusiasts. (Or did
>>I get it all wrong?)
>You didn't get it all wrong, but you missed one essential step: for a
>game to be enjoyable, the parser must be quite capable. The AGT parser
>is probably quite complex and capable (i haven't seen the source, so I
>can't tell how complex), the Advsys parser certainly is, yet neither
>of those are seen to be quite good enough by game reviewers.
I haven't seen any of these parsers or the reviews they got. What is it that
they can't handle? Are the problems actually in the parser, or in the
programmers use of it? Are the reviewers trying to accomplish any goals in the
game, the way an ordinary player would do, or are they hunting for shortcomings
of the parser? (The sample sentence that I initially reacted to is definitely
a case of the latter!)
>Magnus Olsson (m...@df.lth.se)
/Fredrik Ramsberg
Greg Chapman
> When writing in BASIC, there is not support for the same level of
> abstraction that you use in say TADS or Inform, or Lisp for that matter.
> Thus, much of the grammar and parser tables must be a part of the parser
> code.
> If anyone is interested, I'll post the algorithm (with implicit grammar
> etc) for such a parser.
I'm certainly interested! (Happy to have it by e-mail if it's not a popular
request.)
I wrote my first (only) adventures in SHARP MZ80A BASIC, so you realise I'm
quite long in the tooth. Finally, I thought it was time to convert them onto a
PC platform - just to share them with a number of friends and QBASIC is what
I've used so far. (It's been my first exploration of that language, though I
wrote quite a capable BASIC interpreter and compiler for the SHARP (Z80 based)
machine so I'm not a total programming novice.)
As you might imagine I come from the old school of "verb-noun only" input and
cannot see the facination for devising parsers which will cope with "natural
English". That's because generally I'm more interested in having the player
discover the nature of the solutions to the problems I set, rather than
describing those solutions with a very particular set of words.
Do all players these days "insist" on a full parser or are there folks left who
still only ever use the minimalist input approach?
I fear there maybe too many people like Hi-Fi buffs, who spend all the time
talking about wow and flutter pop and hiss and can't actually remember whether
the liked the artist's performance.
Greg
Magnus Olsson
Fredrik Ramsberg <d91f...@isy.liu.se> wrote:
>However, I'm not sure everybody does that interpretation, and I
>still think this kind of answers may give newbies the impression
>that if they can't write a parser this good, they'd better stay
>off the scene all together. If you want to discourage people
>from writing in QuickBasic, hand them alternatives instead of
>just non-constructive criticism of their approach.
You've got a very valid point there. There's been some influx of
newbies to rec.{arts,games}.i-f lately, people who ask "please
tell me some good sites for adventure games" or "please help me
write my own game". Of course, if these people stayed around a
little, they'd find the information they were looking for, for
example from the FAQ lists (the old rule: never post to a group
you haven't read for at least a couple of weeks), but who can
blame them for being impatient to start playing and or coding?
It's important that we don't scare these people away by assuming
that they already know all about the if-archive, the various
authoring systems, and so on.
When we're talking about writing parsers, there is some danger that
we're talking about different things.
Strictly speaking, a parser is a program that parses, i.e. that
performs a grammatical analysis of a sentence. But in adventure games,
one ususally means a lot more than that when talking about the
"parser". Let's first restrict ourselves to the first, more
restrictive sense of "parser".
Writing such a parser from scratch - in Basic, Cobol or any other
language - is a Simple Matter of Programming (tm) nowadays, provided
the language you're parsing is sufficiently simple. Natural English
isn't sufficiently simple, however, it's relatively easy to define
subsets of English that are both sufficiently simple for the parser
and sufficiently powerful for an adventure game(for example, the
subset of English accepted by the Inform parser).
However, let's not forget that it's only a Simple Matter of
Programming if you have the required theoretical background. If you
haven't, then of course you should add the time needed to read up on
formal languages, generative grammar, and parser theory to the time
needed for the actual programming and design. If you don't have that
background, writing a parser from scratch is quite a big undertaking;
you'll either end up with a horrible hack or re-inventing the theory
for yourself :-).
However, this is only part of the story. When people are talking about
an adventure game having a bad parser, it's probably not the parser
itself that's bad. In fact, they could mean several separate things:
1) The parser has too few grammar rules (so that, for example, it
recognizes "Give the rock to the troll" but not "give the troll the
rock").
2) A related case is where you have to type "unlock door with
key", and the parser refuses to recognize "unlock door" or just
"unlock". The incomplete forms should at least ask for the missing
parts, but some bad parsers just say "You can't do that". (Grammar
rules to handle cases like this are known as "error productions" in
compiler theory).
3) The game's vocabulary is too small, so that it doesn't recognize
what the player thinks is reasonable synonyms, or words that are
mentioned in the room descriptions.
4) The game doesn't disambiguate objects in a sufficiently intelligent
way. The command "take egg" shouldn't give the answer "Which egg do
you mean, the hummingbird egg or the ostrich egg?" if you're already
carrying the hummingbird egg. Similar things apply to the scope of
objects (a rose inside a sealed glass container is in scope for the
"look at" action, but not for "smell", so the user interface should
handle the two cases differently).
All of these problems are ususally described as due to a bad parser.
Only 1) and 2) are really parser problems in the usual sense, however,
and only 1) has to do with the complexity and power of the parser.
Perhaps one should talk about "user interface problems" rather than
"parser problems".
For right or wrong, vocabulary and disambiguation are bunched together
with the parser. This means that the task of writing a parser includes
writing disambiguation routines, and that is definitely *not* a Simple
Matter of Programming. In fact, I'm not aware of *any* adventure
writing system that handles it in a totally satsifactory manner;
complicated cases have to be handled with ad hoc programming.
[ Theoretical footnote:
I'm a bit rusty on language theory, but I have a feeling that
whether you label bad disambiguation as a parser problem or not is a
matter of definition. One reason we need disambiguation is that we're
parsing a context sensitive (and game state sensitive) language
(English) as though it were context free; this means that the
sets of tokens making up our terminal symbols aren't constant,
but vary with the game state. But this may be total nonsense.
]
>>>Let's not forget that the goal of making IF stories is to
>>>amuse the player, not to provide pornography for Natural
>>>Language Parsing enthusiasts. (Or did I get it all wrong?)
>
>>You didn't get it all wrong, but you missed one essential step:
>>for a game to be enjoyable, the parser must be quite capable.
>>The AGT parser is probably quite complex and capable (i haven't
>>seen the source, so I can't tell how complex), the Advsys
>>parser certainly is, yet neither of those are seen to be quite
>>good enough by game reviewers.
>
>I haven't seen any of these parsers or the reviews they got.
>What is it that they can't handle?
I haven't analyzed it in depth, but I think it's a combination of
several causes. The general impression I, and most other players and
reviewers, get from AGT games is that the user interface is not quite
adequate.
>Are the problems actually in
>the parser, or in the programmers use of it?
Insufficient vocabulary is clearly the programmer's fault. Some cases of
insufficient grammar are, too, but I have a feeling that the AGT and
Advsys parsers are lacking in error productions, disambiguation and
scoping. These things are usually not under the programmer's control.
The one example where the programmer is in total control is Inform; other
systems such as TADS offer limited control.
>Are the reviewers
>trying to accomplish any goals in the game, the way an ordinary
>player would do, or are they hunting for shortcomings of the
>parser?
Some reviewers try to test the envelope of the parser, but I think
most of them use the same criteria as ordinary players: if the parsing
process gets in the way when trying to accomplish the game goals, then
the parser isn't good enough. If the parser makes it really difficult
to accomplish the goals (such as when it only accepts one possible
wording of a command, rejecting all others without telling why), then
it's usually considered a bug.
To get back to the point:
An adventure game doesn't need a full-fledged natural language parser
that can handle very complicated or ambiguous sentences. Players very
quickly get used to using a special, formalized, idiom ("Troll, go
east, then take all eggs from basket."). However, players also very
quickly get spoiled, and if they're used to games accepting a certain
grammar, then they'll become irritated if a new game doesn't.
So, any new game should have a parser (including diambiguation and
scoping routines) *at least* as powerful as most Infocom games.
Writing such a system from scratch, be it in Basic, Pascal or
Samlltalk, is not an easy task. The parser itself is not the difficult
part, though it will probably take some time.
Therefore, I *strongly* recommend any aspiring authors to use the
existing tools, unless they *really* think they can do better. Or, of
course, if they're more interested in writing parsers than in writing
adventure games.
John Holder
> I see that: d91f...@isy.liu.se (Fredrik Ramsberg) said:
> > If anyone is interested, I'll post the algorithm (with implicit grammar
> > etc) for such a parser.
I, too, am interested...
> I fear there maybe too many people like Hi-Fi buffs, who spend all the time
> talking about wow and flutter pop and hiss and can't actually remember whether
> the liked the artist's performance.
Unfortunately, at some point the wow, flutter, pop, hiss, etc, can get so bad
that even the average listener will be distracted from a performance.
----------------------------------------------------------------------------
John Holder (jho...@nmsu.edu) "Verbing weirds language." - Calvin
Homepage: http://speedracer.nmsu.edu/~jholder
Topics: Homebrewing | Raytracing | Interactive Fiction | Fractals
----------------------------------------------------------------------------
Magnus Olsson
Greg Chapman <gr...@lightning.co.uk> wrote:
>As you might imagine I come from the old school of "verb-noun only" input and
>cannot see the facination for devising parsers which will cope with "natural
>English". That's because generally I'm more interested in having the player
>discover the nature of the solutions to the problems I set, rather than
>describing those solutions with a very particular set of words.
One problem with "verb-noun-only" parsers is exactly that they force
the player to hunt for words. How do you tell the game that you want
to throw the sleeping gas grenade (as opposed to the tear gas grenade)
at the troll (as opposed to at the princess wqhom you're trying to
rescue) with a two-word parser?
In other situations, the two-word parser makes some solutions work as
if by magic. Suppose you have a key that's lying on the other side of
a locked gate. You can't reach it with your ahdnds, but if you're
carrying some long object (like a fishing rod), then you can. If you
only have a two-word parser, then the player will probably find that
"take key" works when he's carrying the rod, but not when he isn't. The
problem is that he may have forgotten that he was carrying the rod...
>Do all players these days "insist" on a full parser or are there folks left who
>still only ever use the minimalist input approach?
I'd say that the majority of IF players today prefer parsers that are
at least as powerful as those of the mid-period Infocom games, and they
will probably be extremely frustrated by a two-word parser.
Note that we're not talking about parsers that understand natural English.
But anything that can't handle sentences with direct and indirect objects,
multiple nouns, and commands to NPC's ("troll, go east") is a relict
from the stone age today (IMAO). Plurals are nice, too.
>I fear there maybe too many people like Hi-Fi buffs, who spend all the time
>talking about wow and flutter pop and hiss and can't actually remember whether
>the liked the artist's performance.
THere's a big difference between music and IF: at least for acoustic
music, the technology is just a recording. You can have a great
performance, record it with inferior technology, and still enjoy it,
because the artistic qualities aren't influenced by the fidelity of
the recording.
With IF, on the other hand, the technology *is* the medium itself. If
you insist on writing IF with a two-word parser, then you're limiting
not just the reproduciton of the game (whatever that would mean), but
the game itself. You're limiting your own expression.
To continue your simile, I'd like to say that the "Hi-Fi buff
behaviour" is pretty rare among IF fans. You often see reviews along
the lines of "I liked this game, despite the bad parser". On the other
hand, insisting on using a two-word parser because it was good enough
for Scott Adams is a bit like a 1990's techno group insisitng on
recording everything in mono, witha frequency range of 200-3000 Hz,
and on scratchy 78-rpm records, because it was good enough for early
jazz artists.
--
----
Magnus Olsson (m...@df.lth.se)
Fredrik Ramsberg
>Greg Chapman (gr...@lightning.co.uk) mentioned in rec.arts.int-fiction that::
>> I see that: d91f...@isy.liu.se (Fredrik Ramsberg) said:
>> > If anyone is interested, I'll post the algorithm (with implicit grammar
>> > etc) for such a parser.
>I, too, am interested...
OK, I'll post it as soon as pressure of classes lightens a little bit,
in a week or so.
>> I fear there maybe too many people like Hi-Fi buffs, who spend all the time
>> talking about wow and flutter pop and hiss and can't actually remember whether
>> the liked the artist's performance.
>Unfortunately, at some point the wow, flutter, pop, hiss, etc, can get so bad
>that even the average listener will be distracted from a performance.
I find both of these views quite valid. In my opinion, the most important thing
to test is whether the average listener gets distracted.
/Fredrik Ramsberg