Does Inform ever expand the description of a room for comparison purposes?

My observation so far is that it doesn’t.

I can create a say phrase for a room description that runs and analyses timer-type code to determine what to print, and it will work fine as soon as it’s seen.

On the other hand, if I make a say phrase for a thing description that runs and analyses timer-type code to determine what to print, it won’t work when first seen, as it will already have run the code for comparison purposes and therefore changed the output to what I wanted the player to see next time, not now.

Do we know if the behind-the-scenes expansion ever happens with say phrases placed in room descriptions?

EDIT - Wait, I’ve done what I did last time. Confused initial appearance (for things) with descriptions (for rooms.)

EDIT EDIT - BUT! It turns out my initial query and what I’ve observed still hold, as this example shows. The room description, Judy’s appearance, and Judy’s description, are all made by say phrases. Only the room description hasn’t already run its code once when each phrase prints its content for the first time.

The parlor is a room. "[parlor-description].".

parlor-is-new-to-you is initially true.

To say parlor-description:
	if parlor-is-new-to-you is true:
		say "The parlor is new to you";
		now parlor-is-new-to-you is false;
		say "The parlor is NOT new to you";

Judy is a woman in the parlor. "[judy-appearance].".

judy-is-new-to-you is initially true.
judy-description-is-new-to-you is initially true.

To say judy-appearance:
	if judy-is-new-to-you is true:
		say "Judy is new to you";
		now judy-is-new-to-you is false;
		say "Judy is NOT new to you";
Description of Judy is "[judy-description].".

To say judy-description:
	if judy-description-is-new-to-you is true:
		say "Judy is description- new to you";
		now judy-description-is-new-to-you is false;
		say "Judy is NOT description-new to you";

test me with "x judy".


I don’t think so.

Looking through the code, there are four rules that check text properties for emptiness:

[the standard examining rule]
if the noun provides the property description and the description of the noun is not “”:

[the use initial appearance in room descriptions rule]
if the item provides the property initial appearance and the item is not handled and the initial appearance of the item is not “”:

[the initial appearance on supporters rule]
if the item is not a person and the initial appearance of the item is not “” and the item is not undescribed:

[the scene description text rule (event is a scene that just started)]
if the description of the event is not “”:

Checks also happen on object article properties (when an object name is printed), and in lots of places in the list writer. (The code that displays lists of items with grouping, etc.)


This is the rule (from the For printing a locale paragraph about rules) that accounts for Judy not being new to us. It’s not in the room description per se, but Carry out looking kicks off the printing the locale description activity, which gets us there eventually.

If an author puts side effects in To-say phrases, it’s on them to test expanding text for comparison purposes to avoid problems. @severedhand , try this:

To say judy-appearance:
	if judy-is-new-to-you is true:
		say "Judy is new to you";
		unless expanding text for comparison purposes, now judy-is-new-to-you is false;
		say "Judy is NOT new to you";

and you’ll see that Judy remains new.

(The docs emphasize this every time they mention expanding text for comparison purposes, which is to say that they don’t. expanding text is unindexed; I presume it’s official that it’s an undocumented feature and not just one of I7’s surprise features.)


There is no difference between “undocumented” and “officially undocumented”. :) If a term isn’t in the documentation, it can’t be in the index.

I think it’s the case that many features that aren’t documented owe to being overlooked and aren’t actually meant to be undocumented features, per se, in the sense that one takes a known risk in depending on them because they’re subject to change without notice. Obviously, that involves some guessing.

In this case, I meant “unindexed” as in defined in the Standard Rules under a section header ending unindexed, hence my use of “officially undocumented” in the sense that there’s a positive declaration of its status, without guesswork.

Oh, sorry. I thought you meant the documentation’s General Index.

You’re right that there’s “undocumented on purpose” and “undocumented by mistake”. The unindexed label in the Standard Rules doesn’t necessarily tell you this, though.

I think that expanding text for comparison purposes is undocumented by mistake.

1 Like

I seem to recall that there used to be a (solitary) example of its use in WI, but since I installed Ver 10 I can’t find it- maybe someone with a persisting Ver 9.3 installation could confirm?

Nope, don’t see it in 6M62.

I never called much attention to it, but lurking in the github pages alongside my webified Standard Rules is the 9.3 docs as a single HTML page, making searching the whole text easy (one does have to “Open all examples” via the link on top first, though, or your browser will ignore the examples’ content).

So I can confirm Andrew’s report of its absence.

(The 10.1 docs as a single HTML page I have, of course, called attention to.)

In the website version of the standard rules, “expanding text for comparison purposes” is listed under the following heading:

§32. Deprecated or private-API-like phrases. None of these are part of Inform’s public specification, and they should be used only by extensions built in to Inform; they may change at any time.

… removing all doubt about whether you strictly should use that phrase, useful as it may be.

If I bring it all back to why I asked my question in the first place – it feels a bit weird that a say phrase in one place has some behaviour and another doesn’t. But I don’t want to gripe about that. I wanted to verify what the actual behaviour is and where.

I’m the kind of person who’s probably never going to use ‘if expanding for comparison purposes’ because it’s like another variable in behaviour I already have to remember. For me, the big deal is I that I can use counter-like programming in a room description say phrase, and that’s a very handy place to be able to use it. In all those other cases we’ve looked at, I will just avoid programming that way. For me, this is the easiest way to handle and remember all this.


Ok, thanks. must be its solitary use in the Standard Rules I was recalling:

Before printing the name of a thing (called the item being printed)(this is the make named things mentioned rule):
    if expanding text for comparison purposes, continue the activity;
    now the item being printed is mentioned.

But this helpful post explains how to go about things, and why :wink:

I’m afraid doubt remains. :) Thing is, that phrase is the only way to correctly manage what looks like a useful technique – a “to say” phrase that updates a flag or counter. I don’t believe the manual says you can do that, but it never says you can’t either.

My reading had been the same as @ArdiMaster’s, but if you’re unsure, now I am too.

I will note that the way I7’s docs (and internal docs, and error messages, and Dr. Nelson’s commentary outside of all of the above) are fond of telling us we shouldn’t be writing I6 inclusions or directly interacting with the I6 layer despite how many useful things would become flatly impossible have left me without an assumption that “desirable and useful thing there isn’t another way to do” is incongruent with “officially unsupported”.

1 Like

I believe—though I’m not certain—that [one of] internally checks this flag to make sure it doesn’t increment the counter unnecessarily. So the officially-supported way to do this is probably to make your code fit the [one of] paradigm.

But also, the docs tell us not to do a lot of things that are extremely useful to do. If a new version actually breaks “expanding text for comparison purposes” I have no doubt that people will immediately mod it back in. I see nothing wrong with doing things this way.

It does.

1 Like