Enclosure in 5Z71 and 6E59?

I haven’t downloaded 6E59 yet, and was trying to help with some code to allow “Bob’s hat” to refer the hat Bob wears, and also to allow “Bob’s nose” to refer to the nose that is part of Bob, and “Bob’s stick” to refer to the stick Bob carries. This is the code I came up with (mostly due to some suggestions from Jim Aikin and Jesse McGrew in response to an earlier question of mine, and incorporating a little of Al’s original code):

[spoiler][code]“possessions” by Matt Weiner

Section 1 - Of Hats

clothing is kind of thing.
a hat is kind of clothing.
clothing is always wearable.

understand “hat” as a hat.

The fuschia hat is a hat. The bright red hat is a hat. The bright blue
hat is a hat. The purple hat is a hat.
The indefinite article of a hat is usually “a”. The description of a
hat is usually “It’s [indefinite article of the noun] [printed name
of the noun].”.

Section 2 - Of Sticks

The swagger stick is a thing. The description is “It seems confident,
if not arrogant.” The walking stick is a thing. The description is
“Sturdy and mostly straight, it looks like it might help you walk.”

Section 3 - Of Noses

A nose is a kind of thing. Every person incorporates a nose.
The description of a nose is usually “[Random person enclosing the
noun][’]s nose is noselike.”

Section 4 - Of Enclosures

After reading a command:
let X be indexed text;
let X be the player’s command;
replace the text “'s” in X with " [’]s";
change the text of the player’s command to X.

Understand “[something related by reversed enclosure] 's” as a thing.
Understand “my” as a thing when the player encloses the item
described.

Section 5 - Scenario

Starter is a room.

Bob and Mike are men in Starter.

Barbie and Sandie are women in Starter.

When play begins: Now Bob wears the red hat. Mike wears the blue hat.
Barbie wears the fuschia hat. Sandie wears the purple hat. Sandie
carries the swagger stick. Mike carries the walking stick.

Persuasion rule: persuasion succeeds.

Test me with “x bob’s hat/x bob’s nose/x sandie’s stick/bob, drop hat/
mike, doff hat/x mike’s hat/mike, take hat/x mike’s hat/bright blue
hat/x mike’s blue hat/mike, wear red hat/mike, drop blue hat/take hat/
x my hat”. [/code][/spoiler]

Except for some weirdness at lines 8 and 9, this behaves well
in 5E71, but apparently it doesn’t in 6Z59; for instance, line 3
yields “I only understood you as far as wanting to examine Sandie’s
nose.” Has the definition of “enclose” changed between 5E71 and
6Z59? I don’t see anything relevant about enclosure in the changelog,
but I noticed that the relevant documentation about enclosing in
3.25 (which is the same in both) doesn’t actually mention
a person’s possessions as something they enclose.

Matt

I’m a bit confused (probably my fault rather than yours). The example code you posted fails to compile at all (the dreaded “Translating the Source Failed” Error of Vaguely Sinister Doom) in Inform 7 6E59 due the line:

The description of a nose is usually "[Random person enclosing the noun][']s nose is noselike."

While that line deserves its own attention, let’s initially stay on course and change it to something mundane like:

The description of a nose is usually "A bridge and two nostrils.  Yep, it's a nose."

This allows the project to compile in 6E59. Line 3 of the “test me” works fine, demonstrating:

>x sandie's stick It seems confident, if not arrogant.
The trouble with lines 8 and 9 of “test me” is that you’ve said in the source:

Understand "[something related by reversed enclosure] 's" as a thing.

Therefore when Mike is carrying two hats, a disambiguation option is the natural result (in other words, the code performs its function as written).

There’s certainly much to be said about this example, but before discussing it we should all be on the same page. Is there more to the code than was posted, or are you relying on second-hand accounts from another person? I’d hate to spend time examining the wrong problem(s).

A possibly relevant thread involving a somewhat similar question is over here.

Well, it did compile in 5Z71 as is, so that’s another question. Does it compile for you if you change “enclosing” to “incorporating”?

Second-hand reports on 6Z59, so we need never speak of that again. The disambiguation option with line 8 was expected and wasn’t the problem; the problem is that in line 9, on typing “bright blue hat” or something similar, I get “I only understood you as far as wanting to examine the bright blue hat.” Which it ought not to say, I think. What do you get after disambiguating?

(I wonder if this has something to do with the after-reading-the-command combined with a disambiguator.)

Anyway, what I posted was the whole code, modulo some inconsequential tweaks.

That doesn’t work either; the built-in relations aren’t understood that way, plus you’ve got the word “noun” in there when you actually want “the item described”. There are many other ways to approach that line, though:

[code]To say noseowner for (nasal - a nose):
let bearer be the holder of nasal;
say “[bearer]'s”.

The description of a nose is usually “[noseowner for the item described] nose is noselike.”[/code]
That seems contrived, though (to me).

You could just write:

The description of a nose is usually "[The holder of the item described][']s nose is noselike."

Which is simple enough, but may become inadequate later if a serial nose collector arrives on the scene with a pair of scissors. The most rigorous way to handle body parts is to make a specific relation, as described in that other thread I linked to in my last post. For example:

[code]Embodiement relates one person (called the bodifier) to various things. The verb to embody (he embodies, they embody, he embodied, it is embodied, he is embodying) implies the embodiement relation.

The description of a nose is usually “[the bodifier of the item described]'s nose is noselike.”

When play begins:
repeat with nosesetup running through people:
let nasal be a random nose enclosed by nosesetup;
now nosesetup embodies nasal.[/code]
Now Mike’s nose will remain Mike’s nose, even if Barbie chops it off with a hatchet.

An unrelated note to this is that your “When play begins” line isn’t functioning as apparently intended. All it really says is:

When play begins: now Bob wears the red hat.
Not that this really matters as far as I can tell; the hats are still properly assigned by declaring them to to be worn by particular people, without any “when play begins” line needed.

[Edited, updated contents below:]

In answer to the general question in your OP, I don’t think the definition of enclosure has changed much.

If for some reason you’re unhappy with your rule:

Understand "[something related by reversed enclosure] 's" as a thing.

There are lots of other ways to approach the same functionality that offer additional room for develoopment. For example you could make an “ownership” relation:

[code]Ownership relates one person (called the owner) to various things. The verb to own (he owns, they own, he owned, it is owned, he is owning) implies the ownership relation.

Carry out an actor taking:
now the actor owns the noun.

Carry out an actor dropping:
if the actor owns the noun:
now the actor does not own the noun.

Understand “[something related by reversed ownership]'s” as a thing.

When play begins:
repeat with mineallmine running through people:
repeat with deedset running through things enclosed by mineallmine:
if mineallmine is carrying deedset or mineallmine is wearing deedset:
now mineallmine owns deedset.[/code]
That’s more work, but could allow you to do other things playing on the ideas of “possession” and “ownership.”

On the general issue of parser confusion, deviating from the “test me” script shows a few new minor confusions. These are mostly solved by adding a few rules such as:

[code]Does the player mean asking someone to try taking off a hat that is worn by the person asked: it is very likely.

Does the player mean asking someone to try dropping a hat that is carried by the person asked: it is very likely.

Does the player mean asking someone to try dropping a hat that is worn by the person asked: it is likely.[/code]
The confusion in regard to the bright blue hat vs the bright red hat is troublesome. Although it can be solved by encouraging the player to make more specific references in the first place, such as:

Does the player mean doing something to the bright red hat: it is likely.

that doesn’t really address the underlying issue. The same problem occurs if someone carries both of the sticks (for example, Bob):

[code]>x bob’s stick
Which do you mean, the swagger stick or the walking stick?

swagger stick
I only understood you as far as wanting to examine the swagger stick.[/code]
I’m sure I’ve seen this issue before, but I can’t remember the details. I experimented a bit, but couldn’t find the underlying problem in the time I had available. One particularly frustrating discovery was that writing:

There is a hat called a bright red hat. There is a hat called a bright blue hat.
did not solve the problem, but that redundantly adding:

There is a hat called a bright red hat. Understand "bright red hat" as the bright red hat. There is a hat called a bright blue hat. Understand "bright blue hat" as the bright blue hat.
does resolve the entire matter. If no one else helps you out on this, I’ll come back to it when I have time just for the benefit of fully understanding the problem myself.

Eh? Isn’t “incorporating” a relation between a thing and its parts anymore?

Good catch; this, as I said, compiled perfectly well in 5Z71, but it’s possible to make it produce undesired results (by making a command that prints the description of Mike’s nose even though the command didn’t mention the nose). If 6E59 won’t compile it, that’s probably a good thing.

[lots of workarounds snipped]

Section 13.4 of the 6E59 documentation still lists the incorporation relation. Assuming I don’t want “Mike’s nose” to refer to a nose that has been detached from Mike and held by Barbie, why should I need to write “holder of the nose” rather than “random person incorporating the nose”? Are you sure that this doesn’t compile and work when you change “noun” to “item described”?

Thanks; that was one of the changes I’ve made in the code I’m actually running.

Nah, as I said the problem was that the guy on RAIF who was testing it in 6E59 reported that “x Sandie’s stick” didn’t work. But he may just have been doing something mysterious. I like my rule fine. :slight_smile:

This looks helpful. I’d thought that something similar (obviously not for hats per se, but for things) was already built in, but perhaps not. And it seems to account for some of the problems that the RAIF guy reported (“Mike, doff hat” led Mike to pick up the red hat from the floor and try taking it off, and then “Mike’s hat” referred to the red hat, and then other weird stuff happened. Now that I think of it, it’s possible he may have changed my code a little before running it. Tsk, tsk.)

Out of curiosity, which commands are leading to trouble?

Yeah, this is the thing that looked like a bug to me. Making it more likely that the player means the bright red hat doesn’t seem like a good idea, since he might not. It might be worth filing a report if we can isolate the problem a little.

Matt

We don’t seem to be writing about quite the same thing; I probably misunderstood your original point. The idea of a relation, called enclosure–which includes containment and incorporation–hasn’t changed. On the other hand using syntax such as “random person enclosing noun” is a horrible idea as it diffuses certainty into mere coincidence. For example:

[code]Include Rideable Vehicles by Graham Nelson.

The Playroom is a room.
A horse is a kind of rideable animal.
Pokey is a horse in the playroom.
Gumby is a person in the playroom.
A person called Mr Mouse is in the playroom. Mr Mouse carries a piece of taffy.

When play begins:
move Mr Mouse to Gumby;
silently try Gumby mounting Pokey.

The description of the taffy is “It’s melting in [random person enclosing the noun]'s hand.”

The description of a person is usually “It’s [item described]. He’s holding [a list of things enclosed by the item described].”[/code]
A “random person enclosing the taffy” could be any of Pokey, Gumby, or Mr Mouse in this example. Sure the line compiles fine and works as exactly as expected–but it’s a bad idea to write such nebulous code. Such poor practices should always be avoided, lest they become habits. On the other hand “list of things enclosed by…” can only ever have a very specific outcome and is therefore a very different sort of rule, despite the fact that both rules use the same terminology.

Folks are certainly free to write whatever they want. My main point is that writing rigorously from the start in a way that encompasses the broadest conceivable circumstances rather than the narrow exigencies of the moment is a best practice, and allows one to easily make major design changes later without reviewing one’s code line by line to update all the work one has already done. An accidental benefit of using this approach is that one generally learns (at a much faster rate) much more about how to efficiently and effectively use I7 than those who try to implement one highly specific scenario at a time. The way I look at the matter is “My hobby time is limited, and I don’t want to waste it doing everything ‘the hard way’ and constantly revising stuff I thought was finished.”

I didn’t experiment any more yet with the odd

There is a hat called a bright red hat. Understand "bright red hat" as the bright red hat.

thing yet, but it’s brewing somewhere in my mind. The solution will pop out on its own any time now; that’s just the way things work for me, and I’ve never been a disciple of the Thomas Edison “99% perspiration, 1% inspiration” approach. In the mean time there’s an extension of the Inform web site called “disambiguation control” that you might look into; I’ve never tried it, but it sounds like it could be very helpful in these circumstances.

Good point about generality, although it applies equally to the “ownership” business, which will start producing bugs as soon as you allow an item to enter or leave someone’s inventory without explicitly being dropped or taken. (Try purloining Bob’s hat and then “x bob’s hat.”)

But we still haven’t addressed the mystery here, which is why

The description of a nose is usually "[Random person enclosing the noun][']s nose is noselike."

didn’t compile for you. Is it that you can’t use “noun” in there anymore?

Disambiguation Control looks like a good thing to look into, and in fact there are some other weirdnesses that I ought to fix if I ever plan to use this (examining Barbie’s stick and Bob’s hat when they don’t have one can yield ambiguous results). But the disambiguation behavior still looks like a bug that shouldn’t require a workaround – if the parser asks you “bright red hat or bright blue hat,” it should take “bright blue hat” for an answer – and perhaps should be reported if it’s still happening in the most recent (now new!) build.

–My scratchpad with the code you originally posted was littered with so many alternatives and examples I forgot about that nose line not compiling originally. I found the problem–when I first started looking at the issues raised in your post, I copied the example code you posted and pasted it into I7. In your OP, the line:

The description of a nose is usually "[Random person enclosing the noun][']s nose is noselike."
as originally posted contains a (hidden) line break after the second instance of the word “the.” In another thread there’s a notice of an updated build of 6E59 (not yet available for my platform, Windows) which contains the following comment:

I wasn’t aware of this bug, and it looks like it hit me while looking at your originally posted example. My later example with Gumby didn’t trigger the bug because it contained no line break in the middle of my text substitution.

So that’s that; apparently this 6E59 bug is to be fixed in a forthcoming update.

–I briefly raised the “ownership” example only to illustrate an alternative way of looking at something; certainly to make it function acceptably a number of practical refinements would need to be added.

–I think, then, all we have left is the problem of:

There is a hat called a bright red hat. Understand "bright red hat" as the bright red hat.

Is that assessment accurate? It’s your thread, and despite my wandering mind (sorry, I’m old, it happens :laughing: ) you deserve to have all your questions answered if possible; everyone else will also likely benefit from an explanation of this unusual problem.

Edited:

Here’s a different way to resolve the hat problem (without using “understand ‘bright red hat’ as the bright red hat” etc):

[code]Understand “hat” as “[tophat]”. Understand “[tophat]” as a hat.

Understand “[something related by reversed enclosure] 's [tophat]” as a hat.[/code]
Sadly that still doesn’t explain the origin of the problem.

Oh, mea maxima culpa; I copied the code from a thread on RAIF (to make sure you were getting the version Al had, not the one with the tweaks I’d made) and didn’t bother to eliminate the line breaks. I wonder if some of his issues came from things he did to tweak non-compiling code. Of course this is a case where pretty much any tweak you make will work, because while you’re tweaking you’ll eliminate the hard line break.

Yes. I think I’ve found the underlying issue; I added this to the end of the “After reading a command”:

say X; say "[line break]".

and steps 8 and 9 produced:

[code]>[8] x mike’s hat
x mike 's hat

Which do you mean, the bright red hat or the bright blue hat?

[9] bright blue hat
x bright blue hat mike 's hat
I only understood you as far as wanting to examine the bright blue hat.[/code]

A little more experimentation shows that what you enter in response to the disambiguation prompt gets put in front of the entire phrase getting disambiguated; for instance if (at the beginning) you enter “x bright hat/bright blue hat,” the player’s command after the response is considered to be “x bright blue hat bright hat”. Which works because any old word salad consisting of the words “bright blue hat” is understood as “bright blue hat.” Also, “x mike’s hat bright blue hat” works if entered as is (whether or not Mike also has another hat) but if you put something (besides “x”) before “mike’s hat” it doesn’t.

I’m not sure whether I think someone should file a bug report in 6E** for this, if it’s still happening. It seems to me that disambiguation ideally ought not to work this way, but it looks like changing the behavior would be a big pain.If someone does want to submit a report, here’s some shorter code that produces the same behavior:

[code]
After reading a command:
let X be indexed text;
let X be the player’s command;
replace the text “'s” in X with " [']s";
change the text of the player’s command to X.
Understand “[something related by reversed possession] 's” as a thing.

Starter is a room. Chris is a person in Starter. Chris carries a red hat. Chris carries a blue hat.

Test me with “x chris’s hat/red”.[/code]

BTW any “After reading a command” code will get executed after a disambiguation response as well as after the original command; as you can see above after the disambiguation response there are two spaces before the “'s,” but it doesn’t matter. This seems like something you have to watch out for if you’re writing “After reading a command,” rather than a bug.

OK, this is completely bizarre. In 5Z71 (as ever), the following yields the bug:

[code]“Hats”

A hat is a kind of thing. Understand “chapeau” as a hat.

Lab is a room. The Stetson is a hat in lab. The fedora is a hat in lab.

Color is a kind of value. The colors are brown, red, and purple. A hat has a color. A hat is usually brown.
After reading a command:
say the player’s command;
say “[line break]”.
Understand the color property as describing a hat. Understand “brown” as brown. Understand “red” as red. Understand “purple” as purple.

Test me with “take brown chapeau/stetson”.[/code]

The following does not yield the bug:

[code]“Hats”

A hat is a kind of thing. Understand “chapeau/hat” as a hat.

Lab is a room. The Stetson is a hat in lab. The fedora is a hat in lab.

Color is a kind of value. The colors are brown, red, and purple. A hat has a color. A hat is usually brown.
After reading a command:
say the player’s command;
say “[line break]”.
Understand the color property as describing a hat. Understand “brown” as brown. Understand “red” as red. Understand “purple” as purple.

Test me with “take brown chapeau/stetson”.[/code]

The following yields the bug again:

[code]“Hats”

A hat is a kind of thing. Understand “chapeau” as a hat. Understand “hat” as a hat.

Lab is a room. The Stetson is a hat in lab. The fedora is a hat in lab.

Color is a kind of value. The colors are brown, red, and purple. A hat has a color. A hat is usually brown.
After reading a command:
say the player’s command;
say “[line break]”.
Understand the color property as describing a hat. Understand “brown” as brown. Understand “red” as red. Understand “purple” as purple.

Test me with “take brown chapeau/stetson”.[/code]

This can’t possibly be desired behavior.

In 6E59, at least, these yield two different versions of the same bug. The first one allows “brown stetson chapeau” or “stetson chapeau brown” but not “stetson brown chapeau”. The second only allows “stetson brown chapeau”, but not “brown stetson chapeau” or “stetson chapeau brown”, or even “chapeau brown stetson”.

This appears to be an issue with the generated parse_name routine only accepting various parts of the name (created by the various Understand statements) in a certain order, and that order changes depending on which types of Understand statements are used.

As you discovered, disambiguation exposes the bug because it works by putting the new words in front of the ambiguous words, which works fine in simple cases where the order doesn’t matter, but doesn’t work in this case. I believe this is a bug in the generated parse_name routine: if you define something called the “brown Stetson chapeau”, the player can type those words in any order, but the parse_name version imposes an undocumented restriction on the order. I recommend filing a bug report.

Good job on nailing this problem down, matt w.

As vaporware suggested, you should send in a bug report about this issue now that it’s been sufficiently explored. If you haven’t done that before the process may seem either slightly intimidating or slightly onerous (or both), but in reality it’s neither of those; I sent one in for 5Z71 and lived to tell about it :slight_smile: . Sending in a bug report is now better than ever, in fact, since it seems the Inform staff may have changed their approach and may be open to the idea of releasing incremental bug-fix updates. Therefore sending in a bug report now means you can help yourself and others avoid a situation like I found myself in over the winter, where I had to set Inform aside because I couldn’t continue working until some bugs were fixed, and the prospect of a new version with bugs fixed was many months away.

Graham is out of town for the week, so if you want your report to be posted immediately, you can file it yourself at the bug tracker site. (Which is a good idea in general now anyway because, among other reasons, the tracker lets you enter more information than the old bug report form.)

Thanks. I was reluctant to file a bug report because I hadn’t verified it myself in 6E, but I’ll do so. (I’m even registered on the forum, though I’ve probably forgotten my password.)

vaporware, thanks for the explanation. The one where the disambiguation doesn’t work seems like a harsher error to me, because the parser asks the player “Stetson or fedora?” and then doesn’t accept the answer, but the “brown stetson hat” one is also mildly bad.

(Though I should really be calling the Stetson a “stetson hat” anyway, as that’s what Staggerlee classically shot Billy Lyons over. I believe its color is not recorded, though its price is.)