[Inform]
Jacek Pudlo
Constant headline "test";
Include ">Libraries/Parser.h";
Include ">Libraries/VerbLib.h";
[Main;
print "Hello world^";
];
Include ">Libraries/Grammer.h";
The above code generates the following error
Expected routine name but foun Maine
Why?
Jake Wildstrom
ITYM "found Main".
Well, parser.h defines a routine Main(). You're trying to define a routine by
the same name, which makes Inform unhappy. There are basically 3 ways to
deal with what you're trying to do, in order of appropriateness:
(1) Leave out all the Include statements. The includes are for when you're
writing a game, and as a result they provide a lot of framework, in particular
the Main() routine. The hook for "stuff you want at the beginning of the
game" is Initialise(). So, leaving out all the include statements will cause
the compiled code to to print "hello world" then crash.
(2) Rename Main() to Initialise(). Then all the code therein will be run
right before the banner is displayed. Then you'll be in a dark room and unable
to do anything except quit. This particular dark room, BTW, is a housekeeping
object called "(Inform Library)", and is the default location of the player.
The Initialise() routine normally has, somewhere in it, a statement of the
form "location = WestOfHouse;" to set the player's initial location.
(3) Add a "Replace Main;" statement above the Includes. Not recommended -- if
you're not going to be using the framework the inform library provides, you're
better off not including it at all. There are routines which it's a good idea
to replace, but Main isn't one of them.
+--First Church of Briantology--Order of the Holy Quaternion--+
| A mathematician is a device for turning coffee into |
| theorems. -Paul Erdos |
+-------------------------------------------------------------+
| Jake Wildstrom |
+-------------------------------------------------------------+
ka...@plover.net
: (1) Leave out all the Include statements. The includes are for when you're
: writing a game, and as a result they provide a lot of framework, in particular
: the Main() routine. The hook for "stuff you want at the beginning of the
: game" is Initialise(). So, leaving out all the include statements will cause
: the compiled code to to print "hello world" then crash.
Not so. If you have a Main function of your own, when control leaves
that function (ie when everything in it is finished) the game ends
normally, which for most interpreters means you see a '[Push any key to
exit.]' prompt. If the game crashed when it was done with Main, every
Inform program would crash.
This is a minor nitpicky detail. You're 100% right about everything
else.
katre
Roger Firth
news:CDEU5.744$O%.129934@newsc.telia.net...
Be careful of the structure of the Inform Designers Manual.
It spends the first six sections introducing Inform as a
general-purpose programming language and talking through
all the basics -- including the need for a Main() routine.
Then, in section seven it abruptly changes direction, stops
treating Inform so generally, and instead focuses on its
primary role as a game design system (in which you don't
start from scratch, but rather ride on the back of a vast amount
of pre-written code which comes in the three Included files).
This false start catches out many beginners and is, IMHO,
the worst fault of the current DM. Sadly, it seems to be
perpetuated in the published contents list for the fourth
edition.
Cheers, Roger
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
You'll find my Cloak of Darkness, Parsifal, Informary
and more at http://homepages.tesco.net/~roger.firth
Jacek Pudlo
eat it" WinFrotz replies "you can't see any such thing." Why?
Neil Cerutti
>I can get the mushroom and I can eat it, but when I type "get
>mushroom and eat it" WinFrotz replies "you can't see any such
>thing." Why?
It thinks it is all one command. It thinks you want to GET:
1. the "MUSHROOM"
2. the "EAT IT"
There isn't an "EAT IT" around, so it prints the error message
you saw.
You need to use a period or the word "then" to seperate
commands on the same line:
>GET THE MUSHROOM AND THEN EAT IT
>GET THE MUSHROOM. EAT IT
--
Neil Cerutti <cer...@together.net>
Linux on board. It is now safe to turn on your computer.
Gadget
wrote:
>You need to use a period or the word "then" to seperate
>commands on the same line:
>
> >GET THE MUSHROOM AND THEN EAT IT
> >GET THE MUSHROOM. EAT IT
>
>--
>Neil Cerutti <cer...@together.net>
>Linux on board. It is now safe to turn on your computer.
The more I learn about inform, the more I realise that Level 9's
parser was actually superior to Infocom's... It could handle the above
just fine and then some... And those games where *tape based*!!
-
It's a bird...
It's a plane...
No, its.. Gadget?
-----------------
number one Dutch gaming site:
Http://www.villagemagazine.nl/games.php3
Andrew Hunter
>On 28 Nov 2000 15:39:19 GMT, cer...@together.net (Neil Cerutti)
>wrote:
>
>
>>You need to use a period or the word "then" to seperate
>>commands on the same line:
>>
>> >GET THE MUSHROOM AND THEN EAT IT
>> >GET THE MUSHROOM. EAT IT
>>
>>--
>>Neil Cerutti <cer...@together.net>
>>Linux on board. It is now safe to turn on your computer.
>
>The more I learn about inform, the more I realise that Level 9's
>parser was actually superior to Infocom's... It could handle the above
>just fine and then some... And those games where *tape based*!!
It's Inform's parser rather than Infocom's, although the Infocom games
do seem to vary with respect to what they can and can't parse (to use
two slightly ridiculous examples):
Here begins a transcript of interaction with
ZORK I: The Great Underground Empire
Copyright (c) 1981, 1982, 1983 Infocom, Inc. All rights reserved.
ZORK is a registered trademark of Infocom, Inc.
Revision 88 / Serial number 840726
>open mailbox
Opening the small mailbox reveals a leaflet.
>take leaflet and eat it
Taken.
I don't think that the leaflet would agree with you.
**
Start of a transcript of THE LURKING HORROR.
THE LURKING HORROR
An Interactive Horror
Copyright (c) 1987 by Infocom, Inc. All rights reserved.
THE LURKING HORROR is a trademark of Infocom, Inc.
Release 203 / Serial number 870506
>take assignment and eat it
You used the word "eat" in a way that I don't understand.
Only found one of those two possible responses from any Infocom game
I've tried; I guess that there are two different parsers in use.
As to Inform, it always assumes that 'and' indicates an object list. Hmm...
<fx: hack, hack, hackity hack>
Start of a transcript of
RUINS
An Interactive Worked Example
Copyright (c) 1995 by Graham Nelson.
Revisited 1998 by Roger Firth.
Release 2 / Serial number 981117 / Inform v6.21 Library 6/10 D
Standard interpreter 1.0 (1Z) / Library serial number 991113
>take mushroom and eat it
You stoop to pick the mushroom, neatly cleaving its thin stalk. As you
straighten up, you notice what looks like a snake in the grass.
You nibble at one corner, but the curious taste repels you.
:-)) That was a pretty evil hack, but it seems to work reasonably well
and doesn't appear to break anything after five minutes of exhaustive
testing. Stick the following code into parserm.h, around line 1948, just
after the
#ifdef DEBUG;
if (parser_trace>=3) print " [Read connective '", (address) o, "']^";'
#endif
lines:
! AH - in the event that this is an and or a comma, check to
! see if the next word is a verb. This rather breaks up the
! structure of the parser, but it can't be helped. Well, it
! probably can, but this is a hack.
if (o==AND1__WD or AND2__WD or AND3__WD or comma_word)
{
! Look ahead to the next word
i = wn;
l = NextWord();
wn = i;
! Could it be interpreted as a verb?
if (l ~= 0 && ((l->#dict_par1) & 1) ~= 0)
{
! Could it still be a noun, though?
! (Not ideal, won't work well if a descriptor like
! 'the' is a verb ;-)
j = wn;
i = NounDomain(actors_location, actor, l);
wn = j;
if (i == 0)
{
if (parser_trace>=3)
print " ['and' or comma seperates two actions]^";
! OK, this is a verb - treat as if it was a then...
wn--;
i=wn*2-1;
parse-->i = THEN1__WD;
jump PassToken;
}
}
}
What this does is check the word following an 'and' or a comma and the
and/comma into an unambiguous 'then' if that word is a verb. Another way
of approaching the problem is to make use of Informs internationalisation
capabilities to change the meaning of the word 'and', although that's not
as neat as you would stop things like 'take mushroom and statue and eat the
statue' from working :-)
Andrew (who has just noticed that Zoom's started adding the object name
from the statusbar into v3 transcripts again...).
--
____
\ \ \ Andrew Hunter <and...@logicalshift.co.uk>
> > > http://www.logicalshift.co.uk (me)
/_/_/ http://www.impulse.org.uk (impulse)
Andrew MacKinnon
(Grammar is misspelled) Spell it Grammar.
Grammar.
--
Andrew MacKinnon
andre...@hotmail.com
http://www.geocities.com/andrew_mackinnon_2000/
Kaia Vintr
>>The more I learn about inform, the more I realise that Level 9's
>>parser was actually superior to Infocom's... It could handle the above
>>just fine and then some... And those games where *tape based*!!
>
>It's Inform's parser rather than Infocom's
If one really wanted to one could probably reverse-engineer the specific
rules used by Level 9's parser and write it in Inform.
>:-)) That was a pretty evil hack, but it seems to work reasonably well
>and doesn't appear to break anything after five minutes of exhaustive
>testing.
What about:
"get eggs and duck"
"fill jug and water lily"
"take paper and sand box"
"give needles and pin cushion to Fred"
"give bullets and staple gun to Fred"
"darn hole and run"
"get clothes and dress Sally"
"move carpet and throw rug"
"reschedule press conference and focus group" (see "NOT a review" thread on
rgif)
I believe your hack just defaults to nouns if there's a conflict, but this
might be confusing for the player.
E.g. I would wonder why does "GET SPOON AND FEED SALLY" work but "GET
CLOTHES AND DRESS SALLY" yield "I only understood you as far as wanting to
get those things"?
-K
Magnus Olsson
Kaia Vintr <ka...@xoe.com> wrote:
>What about:
>
>"get eggs and duck"
>"fill jug and water lily"
>"take paper and sand box"
>"give needles and pin cushion to Fred"
>"give bullets and staple gun to Fred"
>"darn hole and run"
>"get clothes and dress Sally"
>"move carpet and throw rug"
>"reschedule press conference and focus group" (see "NOT a review" thread on
>rgif)
>
>I believe your hack just defaults to nouns if there's a conflict, but this
>might be confusing for the player.
>E.g. I would wonder why does "GET SPOON AND FEED SALLY" work but "GET
>CLOTHES AND DRESS SALLY" yield "I only understood you as far as wanting to
>get those things"?
I think this ties in nicely with one of the "Natural Language Parsing"
threads some time ago, when the point was made that the Inform parser
doesn't really parse the input (in the sense of identifying parts of
speech): it cheats. What it does is some partial parsing combined with
pattern matching, and (here's the cheating part) jumps to a conclusion
as soon as it finds a pattern that matches.
So an Inform-like parser would be confused by a sentence like "get
clothes and dress Sally", because it wouldn't be sophisticated enough
to examine both the possible grammar cases
<command> -> <verb> <noun phrase>
<noun phrase> -> <noun phrase> and <noun phrase>
and
<command> -> <command> and <command>
(In the actual Inform parser, the latter rule doesn't even exist,
probably because if it did, such confusion would be inevitable).
A more sophisticated parser would be able to recognize "dress sally"
as <verb> <noun> rather than <noun> <noun> (I'm using Inform's convention
of not differentiationg between nouns and adjectives).
But even a more sophisticated parser would, of course, be unable to
resolve the ambiguity in
"Give bullets and staple gun to Fred",
because that sentence really is ambiguous.
--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------
Joe Mason
>What about:
>
>"get eggs and duck"
>"fill jug and water lily"
>"take paper and sand box"
>"give needles and pin cushion to Fred"
>"give bullets and staple gun to Fred"
>"darn hole and run"
>"get clothes and dress Sally"
>"move carpet and throw rug"
>"reschedule press conference and focus group" (see "NOT a review" thread on
>rgif)
I must know:
Are any of these taken from Ad Verbum?
If not, will they be used in the sequal?
>FOCUS GROUP
You aim the group carefully, and fiddle with the knob a little until the image
becomes crystal clear.
>FIRE GROUP
A beam of rub light lances out from the group...
Joe
Kaia Vintr
>>FOCUS GROUP
>You aim the group carefully, and fiddle with the knob a little until the
image
>becomes crystal clear.
>
>>FIRE GROUP
>A beam of rub light lances out from the group...
How about...
>PRESS CONFERENCE
The group glows briefly but nothing else happens.
>FOCUS GROUP
You aim the group carefully, and fiddle with the knob a little until the
image
becomes crystal clear.
>PRESS CONFERENCE
A beam of ruby light lances out from the group, neatly incinerating the
Senior VP of Marketing & Communications.
>TRADE SHOW
What do you want to trade the show for?
-K
Andrew Hunter
>In article <zzWU5.21164$2A2.1...@news20.bellglobal.com>,
>>What about:
>>
>>"get eggs and duck"
>>"fill jug and water lily"
>>"take paper and sand box"
>>"give needles and pin cushion to Fred"
>>"give bullets and staple gun to Fred"
>>"darn hole and run"
>>"get clothes and dress Sally"
>>"move carpet and throw rug"
>>"reschedule press conference and focus group" (see "NOT a review" thread on
>>rgif)
>>
>>might be confusing for the player.
>>E.g. I would wonder why does "GET SPOON AND FEED SALLY" work but "GET
>>CLOTHES AND DRESS SALLY" yield "I only understood you as far as wanting to
>>get those things"?
>
>I think this ties in nicely with one of the "Natural Language Parsing"
>threads some time ago, when the point was made that the Inform parser
>doesn't really parse the input (in the sense of identifying parts of
>speech): it cheats. What it does is some partial parsing combined with
>pattern matching, and (here's the cheating part) jumps to a conclusion
>as soon as it finds a pattern that matches.
Well, it can be made to backtrack, assuming you manage to save enough of
its state. There's a new version of my hack up at
http://www.logicalshift.co.uk/etc/ (as the changes are now a bit involved),
which does handle cases like 'get clothes and dress sally' adequately.
I won't go so far as to say that it will handle every case, and I may
have forgotten to restore something required in the backtracking code.
Anyhow, there are now three cases dealt with instead of just the one:
- 'and' inside a multiple-object clause that is followed by an invalid object
- 'and' inside a single-object clause (followed by something that could
be a verb)
- a (final) multiple-object clause that is followed by garbage
In the first two cases, it replaces the 'and' by a 'then' and carries on
parsing. In the final case, it makes a note of the parser's state (word
number, contents of the multiple_objects array and value of 'parameters')
before trying to match against the final token. After matching and finding
garbage, it tries to backtrack to the first and, and checks if it has a
possible verb following it, if so replacing it with a 'then' and restoring
the previously saved state. Obviously replacing 'and' with 'then' is a
blatant kludge :-)
One problem with this is that if you have a grammar rule that did not
match even after backtracking, but a future rule that does, the 'then'
that was added sticks. I can't think of a grammar that would cause this
at the moment, however (it's probably fixable if it is an issue, though).
>So an Inform-like parser would be confused by a sentence like "get
>clothes and dress Sally", because it wouldn't be sophisticated enough
>to examine both the possible grammar cases
>
><command> -> <verb> <noun phrase>
><noun phrase> -> <noun phrase> and <noun phrase>
>
>and
>
><command> -> <command> and <command>
I *think* I've got that covered. But I still have the nagging feeling that
I'm missing something in the backtracking code...
'duck, something' doesn't work in my example, but Inform gets all confused
about that anyway (it could be fixed either by a lookahead to see if the
text before the comma is an animate object, or backtracking again, but this
isn't the problem I'm addressing here ;-).
>(In the actual Inform parser, the latter rule doesn't even exist,
>probably because if it did, such confusion would be inevitable).
>
>A more sophisticated parser would be able to recognize "dress sally"
>as <verb> <noun> rather than <noun> <noun> (I'm using Inform's convention
>of not differentiationg between nouns and adjectives).
>
>But even a more sophisticated parser would, of course, be unable to
>resolve the ambiguity in
>
>"Give bullets and staple gun to Fred",
>
>because that sentence really is ambiguous.
Inform isn't really up to parsing sentences with more than one verb in them,
either :-)
Andrew.
Jacek Pudlo
Kaia Vintr
And how about...
Ambigiuous nouns:
->PUT DIRT IN POT
Don't be redicilous! You can't put anything into the cannabis.
(so this is a 'hippie' game, then why not...)
->SMOKE JOINT
As you set fire to Mad Joe's Bar you realise this was a big mistake.
Ambigiuous nouns + verbs that are homonymous with nouns
->PLANT PLANT NEAR CHEMICAL PLANT
You are not carrying the chemical plant.
Ambigious idioms:
As you watch Karen strutting about in her short dress you can't help
wondering if she is wearing any panties today.
->LOOP UP DRESS
You consult your trusty pocket dictionary. Yepp, it's just what you
expected.
->PICK UP DEAD SQUIRREL
You smooth your hair, test your breath and approach the dead squirrel saying
"Hi georgeous!" The dead quirrel remains strangely unresponsive.
Jumping to conclusions:
->CUT HAIR
You remove your pants and trim your pubic hair. Your genitals never looked
better!
Mentally deficient parser:
->GIVE UP
To whom would you like to give the ceiling to?
Newbie experimenting with Inform:
You're in a dark forest blah blah blah
->X FOREST
You can't see any forest here.
Kaia Vintr
>its state. There's a new version of my hack up at
>http://www.logicalshift.co.uk/etc/ (as the changes are now a bit involved),
>which does handle cases like 'get clothes and dress sally' adequately.
>I won't go so far as to say that it will handle every case, and I may
>have forgotten to restore something required in the backtracking code.
Backtracking... my first thought was to try come up with a command that
takes hours to parse. But no, there doesn't seem to be any danger of
introducing exponential complexity with just these extra rules. (If you
allowed nouns and verbs that start with 'and', then you might be in
trouble!) There's also a practical limit on the sentence length which saves
the parser from too much abuse.
>I *think* I've got that covered. But I still have the nagging feeling that
>I'm missing something in the backtracking code...
It might be possible to implement more robust backtracking using
@save_undo/@restore_undo. It wouldn't work on all interpreters but it would
be interesting...
>>"Give bullets and staple gun to Fred",
>>because that sentence really is ambiguous.
>Inform isn't really up to parsing sentences with more than one verb in
them,
>either :-)
Maybe the parser could prompt to resolve it, e.g.:
> GIVE BULLETS AND STAPLE GUN TO FRED
I'm not sure what you want to do:
A) GIVE THE BULLETS AND THE STAPLE GUN TO FRED
or B) GIVE THE BULLETS AND THEN STAPLE THE GUN TO FRED
(You may type 'A' or 'B')
Of course there's the old problem of accidentally giving away information.
I notice a different noun/verb ambiguity issue now:
>GET
What do you want to get?
>DUCK
You duck under the table.
But that, I guess, is another story.
-K
P.S.:
SPOILER
How do I get the dress off the duck?
Ross Presser
>(If you allowed nouns and verbs that start with 'and', then you
>might be in trouble!)
"Being A Z80"
Your IP is pointing to 4A00.
>LD A,12
You load 12 into the A register.
Your IP is pointing to 4A02.
>LD B,7
You load 7 into the B register.
Your IP is pointing to 4A04.
>AND A,B
The A register now contains 4.
Your IP is pointing to 4A05.
>HLT
** You have died **
--
Ross Presser * ross_p...@imtek.com
A blank is ya know, like, a tab or a space. A name is like wow! a
sequence of ASCII letters, oh, baby, digits, like, or underscores,
fer shure, beginnin' with a letter or an underscore.
Bryce
> But even a more sophisticated parser would, of course, be unable to
> resolve the ambiguity in
>
>
> because that sentence really is ambiguous.
I'm waaay new to this, so forgive me if I'm overlooking something, but it seems to me like there's only one correct interpretation
of this command: "Give the bullets and the staple gun to Fred."
It doesn't make sense to interpret it as "Give the bullets and then staple the gun to Fred," because "give" needs an indirect object
(you have to give them *to* somebody), but there isn't one in "give bullets." "To Fred" is acting as the indirect object of the
second clause, and cannot also apply to the first clause. You couldn't say "I gave a pomegranate and told Fred a joke," but you
could say "I gave Fred a pomegranate and told him a joke." Each clause needs its own indirect object. No?
If that's right, then a smarter parser could work out the apparent ambiguity.
Bryce
-----
>GIVE BULLETS AND STAPLE GUN TO SCHRODINGER'S CAT
The cat watches as you place the bullets and the staple gun on the ground before it, and simultaneously shrieks in pain as the
staple punctures its shiny black coat. It takes a swipe at you and doesn't, scratching your hand with its claws while lowering its
nose to cautiously sniff the inert staple gun.
John D Evans
> >
> >"get eggs and duck"
> >"fill jug and water lily"
> >"take paper and sand box"
> >"give needles and pin cushion to Fred"
> >"give bullets and staple gun to Fred"
> >"darn hole and run"
> >"get clothes and dress Sally"
> >"move carpet and throw rug"
> >"reschedule press conference and focus group" (see "NOT a review" thread on
> >rgif)
And people wonder why getting computers to understand "plain English" is so
difficult.
>give bullets and staple gun to Fred
bullets: "Thanks!" says Fred.
gun: "Ow!" says Fred. "Watch where you staple that thing!"
#!/usr/bin/perl # John Evans jo...@mit.edu http://www.mit.edu/~johne/
while(<STDIN>) # Beware the Radish: http://www.mit.edu/~johne/btr/
{if(/^\d*[13579]$/){$a=$b=$c=1;$_++;until($_==$b){if($_<$b){$_+=$a+=2;}
else{$b+=$c+=2;}}$b=($c-$a++)/2;print $b," ",$a+$b,"\n";}else{die"\n";}}
John D Evans
>
> Your IP is pointing to 4A00.
>
> >LD A,12
> You load 12 into the A register.
>
> Your IP is pointing to 4A02.
>
> >LD B,7
> You load 7 into the B register.
>
> Your IP is pointing to 4A04.
>
> >AND A,B
> The A register now contains 4.
>
> Your IP is pointing to 4A05.
>
> >HLT
>
> ** You have died **
I find this hilarious for reasons which I can't quite figure out and which I'd
probably be rather ashamed of if I could.
Thanks for the chuckle. :)
Kaia Vintr
}"Being A Z80"
}
}Your IP is pointing to 4A00.
>NOP
Time passes.
The kid with the alligator clips is getting impatient.
Your IP is pointing to 4A01.
-K
Ross Presser
(Bryce)".wrote.posted.offered:
>Magnus Olsson <m...@pobox.com>:
>> But even a more sophisticated parser would, of course, be unable
>> to resolve the ambiguity in
>>
>> "Give bullets and staple gun to Fred",
>>
>> because that sentence really is ambiguous.
>
>I'm waaay new to this, so forgive me if I'm overlooking something,
>but it seems to me like there's only one correct interpretation of
>this command: "Give the bullets and the staple gun to Fred."
>
>It doesn't make sense to interpret it as "Give the bullets and then
>staple the gun to Fred," because "give" needs an indirect object
>(you have to give them *to* somebody), but there isn't one in "give
>bullets."
>LOOK
You are behind the counter of a gun shop. There is a carton of .44 dum-dum
handloads on the counter. There is also a .44 Luger on the counter. Howard is
standing on the other side of the counter, carrying his bulletin board, which
for some reason he calls "Fred".
>GIVE BULLETS AND STAPLE GUN TO FRED
You hand the box of bullets to Howard.
Your attempt to affix the Luger to Howard's bulletin board fails, as your
staples are only 2mm deep and the gun is nearly 4cm thick.
[snip]
>If that's right, then a smarter parser could work out the apparent
>ambiguity.
Well, there's always some kind of ambiguity, even between humans. Don't
forget "Time flies like an arrow / Fruit flies like a bannana".
>>GIVE BULLETS AND STAPLE GUN TO SCHRODINGER'S CAT
>The cat watches as you place the bullets and the staple gun on the
>ground before it, and simultaneously shrieks in pain as the staple
>punctures its shiny black coat. It takes a swipe at you and
>doesn't, scratching your hand with its claws while lowering its nose
>to cautiously sniff the inert staple gun.
LOL! This'd make a great signature.
John Elliott
>"Being A Z80"
>
>Your IP is pointing to 4A00.
That's PC. IP is an 8086-ism.
>>HLT
And that should be HALT. HLT is an 8080-ism.
>SLL A
That's not a verb I recognise.
>DEFB 0CBh. DEFB 037h.
A hollow voice says "Nice try."
--
John Elliott
Michael Brazier
wrote:
>Magnus Olsson <m...@pobox.com>:
>> But even a more sophisticated parser would, of course, be unable to
>> resolve the ambiguity in
>>
>> "Give bullets and staple gun to Fred",
>>
>> because that sentence really is ambiguous.
>
>I'm waaay new to this, so forgive me if I'm overlooking something, but
> it seems to me like there's only one correct interpretation
>of this command: "Give the bullets and the staple gun to Fred."
>
>It doesn't make sense to interpret it as "Give the bullets and then staple
>the gun to Fred," because "give" needs an indirect object
>(you have to give them *to* somebody), but there isn't one in "give bullets."
>"To Fred" is acting as the indirect object of the
>second clause, and cannot also apply to the first clause. You couldn't say
>"I gave a pomegranate and told Fred a joke," but you
>could say "I gave Fred a pomegranate and told him a joke." Each clause needs
>its own indirect object. No?
Try "give Fred bullets and staple gun", then -- that can parse to either
"give Fred the bullets and the staple gun" or "give Fred the bullets, then
staple the gun". If "staple" has been defined as a transitive verb, the
parser would have to look for a "staple gun" within the PC's scope to
disambiguate the command(s).
--
Michael Brazier But what are all these vanities to me
Whose thoughts are full of indices and surds?
X^2 + 7X + 53 = 11/3
-- Lewis Carroll
Matthew T. Russotto
John Elliott <j...@seasip.demon.co.uk> wrote:
}rpre...@NOSPAMimtek.com.invalid (Ross Presser) wrote:
}>"Being A Z80"
}>
}>Your IP is pointing to 4A00.
}
} That's PC. IP is an 8086-ism.
}
}>>HLT
}
} And that should be HALT. HLT is an 8080-ism.
}
}>SLL A
}
}That's not a verb I recognise.
Shift Left Logical.
}>DEFB 0CBh. DEFB 037h.
}
}A hollow voice says "Nice try."
What's that do, FORMAT C:?
>rlwinm r30, r30, 4, 0, 28
Use the blasted extended mnemonics, that's what they are for!
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Andrew Hunter
>Andrew Hunter wrote in message ...
[ SNIP ]
>(If you allowed nouns and verbs that start with 'and', then you might be in
>trouble!)
>l at and
Strangely, from some angles, the ampersand looks like it could be just a full
stop after all - or maybe that's just an illusion...
Though the 'and' must be the first noun in an object for this to work
correctly (OK, examine is a bad example, as it only takes one noun, but this
works for take and so forth as well). Inform has a weird bug with scenery
objects and 'and', too - see later.
>>I *think* I've got that covered. But I still have the nagging feeling that
>>I'm missing something in the backtracking code...
>
>It might be possible to implement more robust backtracking using
>@save_undo/@restore_undo. It wouldn't work on all interpreters but it would
>be interesting...
Heh, I had exactly the same thought. Problem is, it'd be a little on the
slow side and it'd disable the usual in-game undo commands.
>>>"Give bullets and staple gun to Fred",
>>>because that sentence really is ambiguous.
>>Inform isn't really up to parsing sentences with more than one verb in
>them,
>>either :-)
>
>Maybe the parser could prompt to resolve it, e.g.:
>
>> GIVE BULLETS AND STAPLE GUN TO FRED
>I'm not sure what you want to do:
> A) GIVE THE BULLETS AND THE STAPLE GUN TO FRED
>or B) GIVE THE BULLETS AND THEN STAPLE THE GUN TO FRED
> (You may type 'A' or 'B')
>
>Of course there's the old problem of accidentally giving away information.
>
>I notice a different noun/verb ambiguity issue now:
>>GET
>What do you want to get?
>>DUCK
>You duck under the table.
>
>But that, I guess, is another story.
Well... not to mention the extra bit of weirdness the backtracking parser
introduces...
>take painting and duck
That's hardly portable.
You duck under the table.
(Only just noticed that...) Now, quite *why* that happens is still a bit
of a mystery to me... Something to do with the way the parser works, because
with the conventional parser:
>take painting, duck
painting of an ampersand: That's hardly portable.
duck: I don't suppose the duck would care for that.
>take painting and duck
I only understood you as far as wanting to take the painting of an ampersand.
So it's the third case that's kicking in. But, commas and ands seem to be
treated in the same way in the parser, so the behaviour of those two commands
should be the same (commas can occasionally seperate commands, but generally
the parser fails to notice that)
>P.S.:
>
>SPOILER
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>How do I get the dress off the duck?
That's one of the two known bugs in the example game - you can't
(the other bug is to get onto the table and then try ducking under it)
Kaia Vintr
>}>SLL A
>}
>}That's not a verb I recognise.
>
>Shift Left Logical.
>
>}>DEFB 0CBh. DEFB 037h.
>}
>}A hollow voice says "Nice try."
>
>What's that do, FORMAT C:?
It's what SLL A would be if it existed in the instruction set. Which is
clever I suppose.
-Kaia (who once wrote his own assembler with his own damn mnemonics)
OKB
>Magnus Olsson <m...@pobox.com>:
>> But even a more sophisticated parser would, of course, be unable to
>> resolve the ambiguity in
>>
>>
>> because that sentence really is ambiguous.
>
>seems to me like there's only one correct interpretation
>of this command: "Give the bullets and the staple gun to Fred."
>
>It doesn't make sense to interpret it as "Give the bullets and then staple
>the gun to Fred," because "give" needs an indirect object
>(you have to give them *to* somebody), but there isn't one in "give bullets."
>"To Fred" is acting as the indirect object of the
>second clause, and cannot also apply to the first clause. You couldn't say
>"I gave a pomegranate and told Fred a joke," but you
>could say "I gave Fred a pomegranate and told him a joke." Each clause needs
>its own indirect object. No?
I don't know if this is strictly correct English, but I see it used quite
a bit. . . Interpret it as "(give bullets) and (staple gun) to Fred". In
other words, the "to Fred" applies to both "give bullets" and "staple gun".
This is often used in sentences like "I used to walk or take the bus to
the store." It doesn't mean I used to: A) walk (destination unspecified); or
B) take the bus to the store. It means I used to A) walk to the store; or B)
take the bus to the store.
--OKB (Bren...@aol.com)
"Do not follow where the path may lead;
go, instead, where there is no path, and leave a trail."
--Author Unknown
Bryce
> I don't know if this is strictly correct English, but I see it used quite
> a bit. . . Interpret it as "(give bullets) and (staple gun) to Fred". In
> other words, the "to Fred" applies to both "give bullets" and "staple gun".
>
> This is often used in sentences like "I used to walk or take the bus to
> the store." It doesn't mean I used to: A) walk (destination unspecified); or
> B) take the bus to the store. It means I used to A) walk to the store; or B)
> take the bus to the store.
That example is a bit different because "to the store" isn't acting as an indirect object in either case, but as an adverb.
However, I suppose you're right that there are people out there who would, in spite of obscure grammar technicalities, type that
sentence intending to staple the gun to Fred, not give him the staple gun. And as the adage goes, the customer is always right.
Bryce
-----
>LOOK
Staples Office Supply, Aisle 27
The aisle runs north and south, walled by shelves full of cardboard boxes.
A clerk, wearing a red knit shirt and a nametag that says "Fred," is here. He keeps his distance, nervously eyeing your staple gun.
Kaia Vintr
>That example is a bit different because "to the store" isn't acting as an
indirect object in either case, but as an adverb.
>However, I suppose you're right that there are people out there who would,
in spite of obscure grammar technicalities, type that
>sentence intending to staple the gun to Fred, not give him the staple gun.
And as the adage goes, the customer is always right.
I think the point has been missed (or obscured). In IF, players are
generally allowed to use an abbreviated grammar:
>GIVE BULLETS
(to Fred)
Fred eagerly accepts the fresh clip and begins firing.
No, this is not correct English syntax by any definition---that particular
meaning of "give" needs a second object (although other uses of "give"
don't, such as "give up" or "give a damn" or...).
But IF players are lazy. And allowing such things leads them to expect and
require less of the parser. I guess the problem is that if you want to
allow more complicated constructions you have to keep the simpler ones
(which perhaps date back to the old two word parsers) as well.
-K
Daniel Barkalow
> "get eggs and duck"
Taken.
Something flashes over your head and embeds itself deep in the henhouse
wall. The duck quacks in frustration, "How did you know?"
-Iabervon
*This .sig unintentionally changed*
Martin Julian DeMello
> I find this hilarious for reasons which I can't quite figure out and which
> I'd probably be rather ashamed of if I could.
> Thanks for the chuckle. :)
Me too :)
--
Martin DeMello
Daniel Barkalow
> On Tue, 28 Nov 2000, Kaia Vintr wrote:
>
> > "get eggs and duck"
>
> Taken.
> Something flashes over your head and embeds itself deep in the henhouse
> wall. The duck quacks in frustration, "How did you know?"
http://iabervon.org/~barkalow/fowl.z5
Interestingly, my unpatched library seems to interpret "duck, get eggs" as
two commands, but "duck and get eggs" not so. This may relate to what
someone found where comma and "and" are treated differently. I'd somewhat
like to have the duck talk, but it doesn't look like I'll be able to.