Working with lists

Hi there,

I have this code:

[There is a room with a man to speak with]

friends is a list of texts variable.
friends is {"word1", "word2", "word3", "word4"}.

Instead of asking the dark figure about [something]:
	if topic understood is listed in friends:
		say "[topic understood] ist in friends".

But is doesn’ work:

[code]Problem. You wrote ‘if topic understood is listed in friends begin’ : but the ingredients in this phrase do not fit it, but I am confused enough by this that I can’t give a very helpful problem message. Sorry about that.
I was trying to match this phrase:

(topic understood - value) is listed in (friends - list of values)
This was what I found out:

topic understood = a non-temporary variable, holding a snippet
friends = a non-temporary variable, holding a list of texts[/code]

How can I deal with “topic understood” in this content?

greetings
textplayer

It’s working fine for me. I added a room and the dark figure:

[code]Lab is a room. The dark figure is a person in the Lab.

friends is a list of texts variable.
friends is {“word1”, “word2”, “word3”, “word4”}.

Instead of asking the dark figure about [something]:
if topic understood is listed in friends:
say “[topic understood] ist in friends”.[/code]

and it compiled and ran. Could there be something else messing it up? If you can post a full compilable program that exhibits the problem, that would help.

Topics are strange creatures.

So there are a few different types of “strings” in Inform. (There used to be even more, but you don’t need to worry about those ones any more, thankfully.)

A “text” is a routine which prints something when it’s called. That’s how you can embed text substitutions into them. You can also “substitute” them to get character-array strings, which you can then work with like in most other languages.

A “snippet” is a pointer into the player’s command, specifying a start and an end point. “The player’s command” is itself a snippet, from the very beginning to the very end.

A “topic” is a parsing routine. It examines a snippet or a text and decides whether or not it matches.

Comparing a snippet against a text, which is what you’re doing here, works…but it’s messy and usually not what you want. The better way is to use a table of topics.

Table of Friends
topic
"word1"
"word2"
"word3"
"word4"

This column now contains topics, not texts, meaning Inform will compile parsing routines for them. You can now write a rule for “Instead of asking the dark figure about a topic listed in the Table of Friends”. Since these are topics, you can also do more fancy things with them.

Table of Friends
topic
"word1" or "word2" or "word3" or "word4"

Hm, running exactly this code gives me:

Ok, i would rather go with a topic table but I have the problem: I want to print out a comma separated list of the available topic entries for the player.

But I can’t print out “[topic entry]” in a say-phrase.This code:

Lab is a room. The dark figure is a person in the Lab.

Table of Friends
topic	response	
"word1"	"answer1"
"word2"	"answer2"
"word3"	"answer3"
"word4"	"answer4"

Instead of asking the dark figure about a topic listed in the table of friends:
	say "[topic entry] is in friends".

gives the following error:

This is the report produced by Inform 7 (build 6G60) on its most recent run through:

Problem. You wrote 'say "[topic entry] is in friends"'  , and in particular 'topic entry': but this asked to say something of a kind which can't be said, or rather, printed. Although this problem can arise when you use complicated text substitutions which come in variant forms depending on the kinds of value used, far more often what this means is just that you tried to use a substituted value (e.g., in 'say "The dial reads [V]."') of a kind which could not be printed out. For instance, if V is a number or a piece of text, there is no problem: but if V is a parsing topic, say an entry in a 'topic' column of a table, then this problem will arise.
I was trying to match one of these phrases:

1. say "topic entry - text" 
2. say "[topic entry - number]" 
3. say "[topic entry - unicode character]" 
4. say "[topic entry - sayable value]" 
5. say "" is in friends" - text" 
This was what I found out:

topic entry = a table entry, holding a topic

What can I really do with topics?

Greetings
textplayer

Ah, OK–we’re using different builds of Inform. It does compile in the latest version, Inform 6M62. One difference between the two versions is that 6G60 distinguishes between “text” and “indexed text,” which can have various string manipulations performed on it; while 6M62 automatically converts things from text to indexed text when needed (there are still differences in how they’re handled, I think, but in 6M62 it’s always OK to refer to your text variables as “text” rather than indexed text). So that might be why your code didn’t work.

One inelegant solution to the problem you had with Draconis’s solution would be to make another column labeled “text” and copy all the entries from the topic column over into it. Then you could consult the topic column when you wanted to check it against the command, and the text column when you wanted to print it.

Oh no, so you have even more types of text to deal with! Amending my previous post for the sake of accuracy:

“Text” is a routine which prints something out. Since it’s a routine, something like “It is currently [time of day].” can show a different time every time it’s run.

“Indexed text” is an array of characters, like in most other programming languages. (I think it’s stored Pascal-style, with the first byte holding the total number of characters, rather than C-style with a terminator, but you never actually need to worry about that.) You can modify individual characters, convert the whole thing to uppercase, and so on. But since it’s just a bunch of characters, it’ll never change unless you change it: text substitutions don’t work any more.

Inform has ways of converting text to indexed text (running the routine and capturing its output), and printing out indexed text, so these differences aren’t as big as they might seem. You just need to remember to convert at the right time. (And remember that an indexed text can never turn back into a normal text.) Using them wrong can hit your performance hard, though.

But back to your actual problem!

Topics, being parsing routines, cannot be printed out. (After all, what should <"[something]'s ghost/spirit" or “the/-- figure”> look like?) One option, as Matt said, is to add a new column to your table holding a text representation. Another option is to use a new kind of value (or “enum”, if we want to continue using jargon).

A friend is a kind of value. The friends are word1, word2, word3, and word4.

Instead of asking someone about "[friend]":
    say "'Ah, you mean [the friend understood]?'".
Instead of asking someone about a topic:
    say "'I know nothing about that.'"

Kinds-of-value can be both parsed and printed out, though unlike topics they can’t contain alternative phrasings or more complicated parsing options.

Thanks for your advice, was really helpful. Where can I get more Information about the handling of topics? I want to know more about the complicated stuff: alternative phrasings and more complicated parsing options.

The included manual in the ide is pretty short about it.