[I7] Descriptions
Dannii
"Laura"
The City of Angels is a room. The incriminating photograph is carried
by the player. The printed name of the incriminating photograph is
"incriminating photograph of a woman with blonde hair". Understand
"woman" or "with" or "blonde" or "hair" or "of" or "a" as the
incriminating photograph.
This works wonderfully with the test, but then allows you to do
nonsense actions like:
>x of
You see nothing special about the incriminating photograph of a woman
with blonde hair.
>x with woman a blonde of
You see nothing special about the incriminating photograph of a woman
with blonde hair.
Now maybe I'm too picky for an example, but I consider this a pretty
big problem and think the example should be revised.
In general, what is the best way for naming stuff in I7?
What about having a regex engine in I7, or some other pattern matching
system? Maybe there's a good reason not too, or maybe just because it's
not 'natural language', but are there reasons? Even something like
using square brackets for optional and vertical bars for alternatives
would be very useful I think. The above could be changed to:
The incriminating photograph is carried by the player. The printed name
of the incriminating photograph is "incriminating photograph of a woman
with blonde hair". Recognise "[incriminating
](photo[graph]|picture|image)[ of a woman[ with blonde hair]]" as the
incriminating photograph.
Andrew Plotkin
> >From Example 133 of the manual:
>
> "Laura"
>
> The City of Angels is a room. The incriminating photograph is carried
> by the player. The printed name of the incriminating photograph is
> "incriminating photograph of a woman with blonde hair". Understand
> "woman" or "with" or "blonde" or "hair" or "of" or "a" as the
> incriminating photograph.
>
> This works wonderfully with the test, but then allows you to do
> nonsense actions like:
>
> >x of
> You see nothing special about the incriminating photograph of a woman
> with blonde hair.
> >x with woman a blonde of
> You see nothing special about the incriminating photograph of a woman
> with blonde hair.
>
> Now maybe I'm too picky for an example, but I consider this a pretty
> big problem and think the example should be revised.
Inform has always worked this way. It has generally not been seen as a
problem.
> In general, what is the best way for naming stuff in I7?
That's not quite an answered question yet, because I7 is not yet as
flexible as it needs to be in recognizing object names. (I think that's
the concensus, at least.)
My current theory is to give each object a unique source-code name
(incriminating photograph), being careful that no object's name is a
subset of another object's name. Then add lots of single-word
synonyms. I use multi-word synonyms (understand "mailbox key"...) only
where a single word might be confusing (e.g., if there is a separate
"mailbox" object).
> What about having a regex engine in I7, or some other pattern matching
> system?
I have never been hot on regexes as a model of IF command recognition.
The main reason is that they're hard to write. Looking at your example:
> "[incriminating](photo[graph]|picture|image)[ of a woman
> [with blonde hair]]" ...
...I don't want to have to write *or* read that. It's not right, in
fact -- you want to put brackets around "a", or it fails to recognize
"photo of woman" -- so I feel justified in saying that the regex model
is more error-prone than what we have now.
Even if you fix that, it excludes some reasonable phrasings like "get
blonde photo", "get photo of blonde", or "examine blonde hair" (which
is quite plausible if there are no blonde women in the room, although
you do want it to disambiguate to Starbuck if she shows up).
A more technical reason: the parser has to make some annoying
compromises to handle cases like:
> X PHOTO
Which do you mean, the incriminating photo of a blonde woman or the
serene photo of Mount Fuji?
> WOMAN
At this point, the parser has the words "photo" and "woman" to work
with, and there's no sensible way to pick out the regexp which matches
that. An undifferentiated bag of words is much easier to work with.
The bag model also lets you group bags together. I7 lets you say
A photograph is a kind of thing. Understand "photo" or "photograph"
or "image" or "picture" as a photograph.
...and then those words are automatically recognized as applying to
all photos in the game. To do this with regexps, you have to start
defining regexps that invoke other regexps, which is much more work.
And once multi-word phrases start showing up in the "inner" regexps,
it rapidly becomes impossible to name all the orderings that the
player might type.
I'd say I7 needs, at minimum, a way to mark certain words (of an
object) as "don't accept these on their own", or "don't accept these
without this other word also present." Those are the parsing patterns
that I found most useful in I6. A general word-accepting routine would
of course also be nice; the parse_name model of I6 was cumbersome, but
maximally flexible.
I can see a simplified regex-like model -- at least a hierarchical
list of words and phrases, as in your example -- as something which
could be written as an I7 extension.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
It's a nice distinction to tell American soldiers (and Iraqis) to die in
Iraq for the sake of democracy (ignoring the question of whether it's
*working*) and then whine that "The Constitution is not a suicide pact."
Dannii
> ...I don't want to have to write *or* read that. It's not right, in
> fact -- you want to put brackets around "a", or it fails to recognize
> "photo of woman" -- so I feel justified in saying that the regex model
> is more error-prone than what we have now.
Although I suppose it is polite to recognise "photo of woman", "woman"
is not a proper name, and so it could legitimately be rejected. "x
woman" by itself should also be rejected, as there is no woman thing
within scope (if you really wanted to put so much detail into a photo
you would probably make an assembly, so there would then be a woman
object within scope). I'm not saying these should be always rejected by
the parser, but that the writer should work at it so that they are
recognised correctly, instead of just being a byproduct of sloppy
naming.
> The bag model also lets you group bags together. I7 lets you say
>
> A photograph is a kind of thing. Understand "photo" or "photograph"
> or "image" or "picture" as a photograph.
That looks nice, I'm only just getting into I7 today. However with that
kind/class, would the original have to be changed to "The incriminating
photograph is photograph"?
> I'd say I7 needs, at minimum, a way to mark certain words (of an
> object) as "don't accept these on their own", or "don't accept these
> without this other word also present." Those are the parsing patterns
> that I found most useful in I6. A general word-accepting routine would
> of course also be nice; the parse_name model of I6 was cumbersome, but
> maximally flexible.
>From what I remember of I6, the parser would score each word it's given
to determine what you're trying to refer to, and if it couldn't then it
would ask the user specifically. So if your above idea was implemented
you could say that "of", "a", "an" etc are not to be used individually,
but if included in the list of "Understand ... as ..." then they would
score higher?
Andrew Plotkin
> Andrew Plotkin wrote:
> > ...I don't want to have to write *or* read that. It's not right, in
> > fact -- you want to put brackets around "a", or it fails to recognize
> > "photo of woman" -- so I feel justified in saying that the regex model
> > is more error-prone than what we have now.
>
> Although I suppose it is polite to recognise "photo of woman", "woman"
> is not a proper name, and so it could legitimately be rejected. "x
> woman" by itself should also be rejected, as there is no woman thing
> within scope (if you really wanted to put so much detail into a photo
> you would probably make an assembly, so there would then be a woman
> object within scope).
Maybe and maybe not. You don't always want to break game-world objects
up into as many parts as possible.
> I'm not saying these should be always rejected by
> the parser, but that the writer should work at it so that they are
> recognised correctly, instead of just being a byproduct of sloppy
> naming.
I don't think either model is "correct" or "sloppy" -- it's solely a
matter of what works best for both the player and the author. Going to
extra work to reject "photo of of a woman" seems perverse.
> > The bag model also lets you group bags together. I7 lets you say
> >
> > A photograph is a kind of thing. Understand "photo" or "photograph"
> > or "image" or "picture" as a photograph.
>
> That looks nice, I'm only just getting into I7 today. However with that
> kind/class, would the original have to be changed to "The incriminating
> photograph is photograph"?
Yes. (Although, actually, I ran into some compile-time confusion when I
tried to have a kind called "foo" and an instance called "bar foo".
But that's separate from parsing of player commands.)
> > I'd say I7 needs, at minimum, a way to mark certain words (of an
> > object) as "don't accept these on their own", or "don't accept these
> > without this other word also present." Those are the parsing patterns
> > that I found most useful in I6. A general word-accepting routine would
> > of course also be nice; the parse_name model of I6 was cumbersome, but
> > maximally flexible.
>
> >From what I remember of I6, the parser would score each word it's given
> to determine what you're trying to refer to, and if it couldn't then it
> would ask the user specifically.
I6 didn't have a score for individual words. Each individual word was
accepted or rejected, and an object matched a sequence of consecutive
accepted words. (Articles and pronouns -- a/an/the/some/my and so on
-- were handled specially. "Of" was not considered special except in
combinations like "some of" or "three of".)
> So if your above idea was implemented
> you could say that "of", "a", "an" etc are not to be used individually,
> but if included in the list of "Understand ... as ..." then they would
> score higher?
The parser already ignores "a" and "an" (mostly -- I'm simplifying).
And I think it's okay to stick with the accept/reject model for words.
I'd be happy to just say "this object should accept 'of' if it also
has 'photo/photograph/picture'".
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't subjected you to searches without a warrant,
it's for one reason: they don't feel like it. Not because you're an American.
Adam Thornton
Andrew Plotkin <erky...@eblong.com> wrote:
>My current theory is to give each object a unique source-code name
>(incriminating photograph), being careful that no object's name is a
>subset of another object's name. Then add lots of single-word
>synonyms. I use multi-word synonyms (understand "mailbox key"...) only
>where a single word might be confusing (e.g., if there is a separate
>"mailbox" object).
This is an interesting I7 problem. I am torn between a keyword- and and
object-recognition conversation system for exactly this reason.
Adam
Andrew Plotkin
You can always make objects with single-word names, so objects are
strictly more powerful, right?
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
It used to be that "conservatives" were in favor of smaller government,
fiscal responsibility, and tighter constraints on the Man's ability to
monitor you, arrest you, and control your life.
Adam Thornton
Andrew Plotkin <erky...@eblong.com> wrote:
>You can always make objects with single-word names, so objects are
>strictly more powerful, right?
Yeah, but there are also lots of conversational topics that are never
actually referenceable objects in the game, so then I have to come up
with a whole bunch of new scoping stuff as well.
It's a pain.
Adam
Neil Cerutti
> I'd say I7 needs, at minimum, a way to mark certain words (of
> an object) as "don't accept these on their own", or "don't
> accept these without this other word also present." Those are
> the parsing patterns that I found most useful in I6. A general
> word-accepting routine would of course also be nice; the
> parse_name model of I6 was cumbersome, but maximally flexible.
>
> I can see a simplified regex-like model -- at least a
> hierarchical list of words and phrases, as in your example --
> as something which could be written as an I7 extension.
That was basically the design behind pname.h (after it was cut
down from something much more feature-rich--and in fact, I think
it could do with fewer features still).
But it involved sadly hacking the code dealing with building up
match_list, rendering it Library 6/10 exclusive.
There's as yet no way I can see to port it to Inform 7.
--
Neil Cerutti
Smoking kills. If you're killed, you've lost a very important
part of your life. --Brook Shields
Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
Neil Cerutti
>> but that the writer should work at it so that they are
>> recognised correctly, instead of just being a byproduct of
>> sloppy naming.
>
> I don't think either model is "correct" or "sloppy" -- it's
> solely a matter of what works best for both the player and the
> author. Going to extra work to reject "photo of of a woman"
> seems perverse.
I agree that "photo of of a woman" should not be rejected; that
would be a waste of effort. But it ought to rank lower than
"photo of a woman".
--
Neil Cerutti
Andrew Plotkin
> On 2006-06-11, Andrew Plotkin <erky...@eblong.com> wrote:
> >> I'm not saying these should be always rejected by the parser,
> >> but that the writer should work at it so that they are
> >> recognised correctly, instead of just being a byproduct of
> >> sloppy naming.
> >
> > I don't think either model is "correct" or "sloppy" -- it's
> > solely a matter of what works best for both the player and the
> > author. Going to extra work to reject "photo of of a woman"
> > seems perverse.
>
> I agree that "photo of of a woman" should not be rejected; that
> would be a waste of effort. But it ought to rank lower than
> "photo of a woman".
Inform ranks objects for a given input, not vice versa.
I assume what you mean is that if the location contains "photo of of a
woman" and "photo of a woman", and the player types the former, the
parser should choose the former over the latter. (Not that that's
likely to happen in a real game -- but other analogous cases could.)
I agree, but I'm not sure it's important enough to be worth
complicating the rest of the system.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
"Bush has kept America safe from terrorism since 9/11." Too bad his
job was to keep America safe *on* 9/11.
Neil Cerutti
>> I agree that "photo of of a woman" should not be rejected;
>> that would be a waste of effort. But it ought to rank lower
>> than "photo of a woman".
>
> Inform ranks objects for a given input, not vice versa.
>
> I assume what you mean is that if the location contains "photo
> of of a woman" and "photo of a woman", and the player types the
> former, the parser should choose the former over the latter.
I mean that if there's a "photo of a woman" in scope, and the
player types "photo of a woman" that should be preferred to any
other combination of those words. So "woman" can refer to the
"photo of a woman", but not if a "woman" is in scope. If that
makes more sense.
Andrew Plotkin
> >> I agree that "photo of of a woman" should not be rejected;
> >> that would be a waste of effort. But it ought to rank lower
> >> than "photo of a woman".
> >
> > Inform ranks objects for a given input, not vice versa.
> >
> > I assume what you mean is that if the location contains "photo
> > of of a woman" and "photo of a woman", and the player types the
> > former, the parser should choose the former over the latter.
>
> I mean that if there's a "photo of a woman" in scope, and the
> player types "photo of a woman" that should be preferred to any
> other combination of those words. So "woman" can refer to the
> "photo of a woman", but not if a "woman" is in scope. If that
> makes more sense.
That makes sense, but what if there's a "blonde woman" or "Judy/woman"
in scope? In a well-tested game, there will always be synonyms or
adjectives that the player didn't type. The feature is not very useful
if the author has to go through and exhaustively list all word
combinations that rank high.
On the other hand, it is often reasonable to have a list of words
which rank high for an object when standing alone. That would be a
useful thing to make easy.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't thrown you in military prison without trial,
it's for one reason: they don't feel like it. Not because you're patriotic.
Neil Cerutti
> Here, Neil Cerutti <lead...@email.com> wrote:
>> I mean that if there's a "photo of a woman" in scope, and the
>> player types "photo of a woman" that should be preferred to
>> any other combination of those words. So "woman" can refer to
>> the "photo of a woman", but not if a "woman" is in scope. If
>> that makes more sense.
>
> That makes sense, but what if there's a "blonde woman" or
> "Judy/woman" in scope? In a well-tested game, there will always
> be synonyms or adjectives that the player didn't type. The
> feature is not very useful if the author has to go through and
> exhaustively list all word combinations that rank high.
In practice, it works well in ambiguous situations, and gives you
the power you need. You only need to write word combinations to
resolve cases that might conflict. Basically, you'd need phrases
in the same situations that you needed parse_name, but they work
better.
What happens in the situation you describe will depend on how you
designed the phrases.
I'll assume the following setup (this isn't pname.h syntax, but
a spiffy I7 version of it):
Understand "photo of a woman" as the photo.
Understand "blonde woman" as the woman.
Understand "woman" as Judy.
You see a photo of a woman, a blonde woman, and Judy here.
> X WOMAN
Which do you mean, Judy or the blonde woman?
(The photo of a woman, ranking beneath Judy and the blonde since
none of its phrases were matched, doesn't enter the conversation
unless Judy and the blonde are out of scope. Judy and the blonde
both had a phrase matched, so they rank equally and need help
from the player)
> JUDY
(The parser sees 'woman' 'judy'... This does not match to any
phrase, so we fall back to the currently standard parsing
algorithm, which most closely matches Judy. The standard
algorithm does need to be extended to be able to look into
phrases for individual word matches for this to work.)
Judy is reading a blue-leather bound version of "The Reader's
Digest Condensed Books Inform Designer's Manual by G.Nelson."
> X WOMAN
Which do you mean, Judy or the blonde woman?
> BLONDE
(Parser sees 'woman' 'blonde', and selects the blonde.)
The blonde woman is ignoring your lewd stares.
> X PHOTO
Anna Nicole Smith smiles out at you, recovering from her 20th
law-suit to keep her millions.
> X OF PHOTO
(The "dumb" part of the parser falls back on the photo since it's
the only object containing both 'of' and 'photo' in any phrase.)
Anna Nicole Smith smiles out at you, recovering from her 20th
law-suit to keep her millions.
--
Neil Cerutti
If only faces could talk. --Pat Summerall
Dannii
Understand "photo" or "of" or "a" or "woman" as the photo.
Understand "blonde" or "woman" as the woman.
Understand "woman" as Judy.
Neil Cerutti
Yes. In this case, all my example inputs would be phrase matches,
and hence rank equally.
> X WOMAN
Which do you mean, the photo of a woman, Judy, or the blonde
woman?
> JUDY
She's reading the Reader's Digest...
> X WOMAN
Which do you mean, the photo of a woman, Judy, or the blonde
woman?
> BLONDE
She ignores your lewd stares.
> X OF PHOTO
Anna Nicole Smith...
This is a case where phrases were not really needed after all.
The player had enough information to be able to provide enough
help to the parser. The only difference was that the parser
could't rule out the photo right away in the first two instances.
Phrase matching would be *necessary* if the woman provided no
other names other than "woman":
The current parser:
There is a woman here. There is a photo of a woman here.
> X WOMAN
Which do you mean, the woman or the photo of a woman?
> WOMAN
Which do you mean, the woman or the photo of a woman?
> WOMAN WOMAN WOMAN!
Which do you mean, the woman or the photo of a woman?
But with proper understanding of phrases:
There is a woman here. There is a photo here.
Understand "photo of a woman" as the photo.
> X WOMAN
(Matches a phrase meaning the woman, but not one meaning the
photo, so the photo is discarded
from the match list)
She ignores your lewd stares.
--
Neil Cerutti
The choir invites any member of the congregation who enjoys
sinning to join the choir. --Church Bulletin Blooper
ems...@mindspring.com
For the next release, I have added the following to the end of the
Laura example:
One possible objection to this solution is that Inform will accept some
nonsensical formulations as applying to the photograph: for instance,
it will allow EXAMINE PHOTOGRAPH OF, X BLONDE PHOTOGRAPH WOMAN
INCRIMINATING, or even X OF ...though in the case there were two items
with "of" names, the game would disambiguate with a question such as
"Which do you mean, the incriminating photograph of a woman with blonde
hair or the essence of wormwood?"
Traditionally, Inform has tended to be fairly flexible about word
order, preferring to err in the direction of leniency. On the other
hand, there are times when we need more exacting rules in order to
distinguish otherwise similar cases.
Two features allow us to specify more exactly if we so desire. The
first is that, if we specify a whole phrase as the name of something,
all the words in that phrase are required, in the order given. Thus
"Understand "blonde hair" as the photograph" would require that both
"blonde" and "hair" be present, and would not recognize >X BLONDE, >X
HAIR BLONDE, or >X HAIR.
Second, we can create tokens, such as "Understand "blonde hair" or
"hair" as "[hair]", and then use these tokens in match phrases. This
saves a good deal of time when we want to specify a number of different
but fussy alternatives. So, for instance, here is a drawing that would
not respond to >X OF, or >X BROWN EYES, but would respond to >X DRAWING
OF MAN WITH BROWN EYES, >X MAN WITH BROWN EYES, and so on:
The drawing is carried by the player. The printed name of the drawing
is "drawing of a man with brown eyes".
Understand "eyes" or "brown eyes" as "[brown eyes]". Understand "man"
or "man with [brown eyes]" or "brown-eyed man" as "[man]". Understand
"[man]" or "drawing of [man]" or "drawing of a [man]" as the drawing.
Test me with "test one / test two".
Test two with "x drawing / x man / x of / x drawing of man / x drawing
of a man / x drawing of a man with brown eyes / x drawing of a
brown-eyed man / x brown eyes".
Yet further refinements are possible; for a full discussion of how
Inform understands names of objects, we should refer to the chapter on
Understanding.
----
Admittedly, this does not deal with all of the issues about object
preference when multiple things are in scope with names that should be
weighted differently. Some of that can be approximated with "understand
when..." rules, introduced much later in the manual, and some of it
still awaits some better internal syntax.