I wrote the following code, where stuff gets confiscated if you go beyond a certain point.
[code]“tackiness” by Andrew
A thing can be tacky. A thing is usually not tacky.
The spinning glow-in-the-dark bow tie is tacky. The beer drinking hat is tacky. The bottle of champagne is a thing. The expensive cheese is a thing.
the bow tie is carried. the hat is carried. the bottle is carried. the cheese is carried.
The porch is a room. “Go east to test this short program.”
Party Central is east of the porch. lalaland is a room.
check going east: [below, adding ‘list of’ cuts off what you have. The first try works ok but the second doesn’t. Why does it do this, and how would I know this?]
repeat with Q running through things carried by the player:
[repeat with Q running through list of things carried by the player:]
if Q is tacky:
now Q is in lalaland;
say “Oh my goodness they confiscated [the list of things in lalaland]!”
test seized with “e”[/code]
The bow tie and hat are confiscated here, as expected.
But the second “repeat,” if de-commented (with the first commented,) only confiscates the bow tie.
Why does “list of” have this sort of power? Is this a bug, or is there a reason it gives different behavior e.g. as a way to break out of the loop without having booleans like
if Q is tacky and something-confiscated is false:
now something-confiscated is true;
now Q is in lalaland;
Changing a list while you’re iterating through it is risky in any computer language. I7 has some protection against this, but you seem to have worked around it by using a dynamic list together with a manual loop.
The usual way to do this, which avoids the whole problem, is:
now all tacky things carried by the player are in lalaland.
Thanks very much! I’ll remember this next time something seems more complicated than it should be. I can forget that Inform’s natural language can be, well, even more natural than it seemed on first impression.
The problem with the original code is that I7 re-evaluates “list of things carried by the player” on each iteration: it’s not working with the same list on each iteration, which is surely a bug.
I’ve filed a report for this, with a test case illustrating that the problem isn’t related to changing the object tree or shortening a list while looping over it: inform7.com/mantis/view.php?id=968