Nested substitutions too complicated?

I’m not sure why but Inform calls this too complicated:

The initial appearance of the Enchantress is "[if the Sewer is unvisited]Some text[otherwise][if the current action is not looking][line break][end if]Some other text[end if]."

The reason for the “if current action” check is because Inform has trouble it seems with various line breaks depending on what else is being printed. If that nested check is not in place, there is no problem.

As it is, Inform says “a second substitution occurs inside an existing one, which makes this text too complicated.” From a pure programmatic standpoint that makes no sense, so I’m trying to understand what Inform is actually having trouble dealing with here. Rather than fight with Inform, I’m open to ideas on how best to handle this.

Okay, on closer reading of the error, it looks like I can do this:

To say appearance break:
	if the current action is not looking, say "[line break]".

The initial appearance of the Enchantress is "[if the Sewer is unvisited]Some text[otherwise][appearance break]Some other text[end if]."

I get why it looks easier visually, but why is that actually not “too complicated” for Inform?

Inform doesn’t allow a substitution to nest inside itself. In other words you can’t have an [if] inside an [if], or a [one of] inside a [one of].

Is there a rationale for this that has been published? I’m fine working within the constraint. I’m just one of those people that needs to know why the constraint exists. For example, in general coding this is perfectly fine:

if condition
    if sub-condition
    end
end

There is no reasonable programmatic sense to say this is “too complicated.” I realize Inform does allow this in the context of if phrases, so this appears to rest entirely upon the fact that these conditions are being used in a substitution.

Making clear here I’m not some curmudgeon who refuse to use it as it is: I’m just curious why.

You’re able to use indentation to indicate which “if” an “end” is ending in normal code, but you can’t in a substitution. That would be the main issue I imagine.

I suspect this has to do specifically with the way segmented substitutions work. See §27.28-30 of Writing with Inform (the last three sections of the documentation). I don’t know the internals of how they get compiled at all, but it looks as though when dealing with segmented text substitutions there’s some special stuff that the compiler has to do to hook up the segmented substitution’s parts together. My guess is that this stuff involves saying something like “When you see a token that begins this substitution, look for the next token that can end the substitution,” but that it would add a lot more complication to the compiler to allow nesting.

By the way you can use “otherwise if” which lets you do your example in one line, though not elegantly:

The initial appearance of the Enchantress is "[if the Sewer is unvisited]Some text[otherwise if the current action is not looking][line break][end if][if the Sewer is visited]Some other text[end if]."

EDIT-ADD: Also also, either way we do this, I think we get a spurious line break when we’re printing the room description after going into the room where the Enchantress is. Not sure how to deal with this.

I have struggled with this a lot. I usually have to fidget with trailing spaces within the text of the substitution and sometimes I get it to work and sometimes I don’t. I’ve wondered if building a routine to construct a complicated substitution as a stored text and then using that for the substitution might work better and avoid superfluous spaces, but I’d need to read up on how to do it.

With regard to the original question: the library uses the initial appearance property only while looking. Are you using the property in some extended way, to require this “current action is not looking” check?

It might be easier to refactor this in some way.

A thing has a text called the long-description.
The initial appearance of a person is "[long-description of the item described]."

The Enchantress is a person in the Kitchen.

The long-description of the Enchantress is "If this then that etc".

Note that I have kept the closing punctuation outside the long-description property; there’s a period in the initial appearance, and anywhere else long-description is used. This is a simple trick that works for a lot of cases. (Sadly, not all cases. Occasionally you want to end a paragraph with a question mark or a close-paren or something.)

No better, in my experience.