Lists of Values

I’m trying to do something that would be very, very easy in TADS, but the Inform compiler doesn’t like the syntax I’m trying to use, and the Documentation does not, as far as I can see, explain how to do it.

This first line seems to compile (unless the compiler gave up before it got there, which is not likely since I put it near the top of the code):

A color is a kind of value. The colors are red, orange, yellow, green,
blue, violet, pink, and gray.

However, this code does not compile:

The rhinoceros-solution is a list of colors. Let rhinoceros-solution
be {pink, yellow, green, blue}.

(Note: There is no rhinoceros in the game. I’m obfuscating to avoid a spoiler.)

The compiler reports, Problem. The sentence ‘The rhinoceros-solution is a list of colors’ [This] reads to me as if ‘rhinoceros-solution’ refers to something I should create as brand new - a list of colors. But that can’t be right, because this is a kind of value where I can’t simply invent new values."

Well, yes, it IS correct, because I’m not inventing new values! I’ve already declared that the colors are a kind of value.

What I need is precisely what I’ve written: a list of four colors, which I will then need to compare to another list of four colors, and I don’t know how to do that either. Iterating through a list with a variable as a pointer to the entry in a list is probably something I can figure out myself … but then how do I compare the entry in one list with the entry in the other list? Using an equals sign? Why am I not confident that that will work?

I’m sorry, but this appears to be one of those cases where the Documentation fails by trying to be too friendly. It tries to guess what the author probably wants, rather than explaining precisely how the code can and cannot work.

1 Like

No missing words this time, I promise. Any of these work:

The rhinoceros-solution is initially {pink, yellow, green, blue}.

The foo is a list of colors that varies.
The foo is {pink, yellow, green, blue}.

The bar is always {pink, yellow, green, blue}.

The first two create variables; the last is a constant.

And comparing two lists with “is” should just work. Or comparing individual entries with if entry 1 in foo is entry 1 in bar.

2 Likes

Thanks. That seems to work. It’s still very unclear to me how one would iterate through a list using a loop. The phrase “entry index” (where the loop variable is called “index”) doesn’t seem viable. But since all I need is for the two lists as a whole to be compared, it seems to work.

Either of these work.

[ if you don't need the index number ]
repeat with x running through foo begin;
  say "x [x].";
end repeat;

[ if you do ]
repeat with i running from 1 to number of entries in foo begin;
  let y be entry i in foo;
  say "y [y].";
end repeat;

or, what the heck, I’ll plug my own extension Strange Loopiness, available for 9.3/6M62, soon to be ported to v10 unless I encounter some fundamental reason I can’t. With it, either of these would work.

  repeat for color-val in foo begin;
      say "color: [color-val].";
    end repeat;

    repeat for other-color-val in foo with index i begin;
      say "color [i]: [other-color-val].";
    end repeat;
1 Like

Jim, you didn’t quote the whole of the compiler message. The rest was

Perhaps you wanted not to invent a constant but to make a variable - that is, to give a name for a value which will change during play. If so, try something like ‘The bonus is a number which varies’.

Or perhaps you wanted to create a name as an alias for a constant value. If so, try something like ‘The lucky number is always 8.’ But this only makes a new name for the existing number 8, it doesn’t invent a new number.

which seems to go at least some way to cluing the correct syntaxes.

I agree that the documentation is often frustrating in its refusal to engage with the nuts and bolts of the language.

2 Likes

That’s why I wrote my Handbook. But even with the Handbook, I’m just scratching the surface. It’s as incomplete as the Docs, just in a different way.