Studying Inform 6 parser -- baffled by Adjudicate

Authoring Inform 6
1

Hi forum,

Long time Inform fan, first time poster.

I have a little bit of a weird question. At about line 3206 of the parserm.h file provided with Inform Release 6/11 – Serial number 040227… I find the following code:

for (i=0 : i<number_matched : i++) match_classes-->i = 0; n = 1; for (i=0 : i<number_matched : i++) if (match_classes-->i == 0) { match_classes-->i = n++; flag = 0; for (j=i+1 : j<number_matched : j++) if (match_classes-->j == 0 && Identical(match_list-->i, match_list-->j) == 1) { flag=1; match_classes-->j = match_classes-->i; } if (flag == 1) match_classes-->i = 1-n; } n--; number_of_classes = n;

Near as I can tell, this code is just taking a bunch of possible matches and attempting to group the matches by class and similarity, or something.

However, when I debug this code during runtime, I find that the outermost for loop is being executed only one single time.

I cannot figure this out. It appears that match_classes should look something like this where number_matched == 17 :
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17]

But it does not. Running in Frotz V2.43, it instead looks like this:
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

What is going on here?

2

When you added debugging, did you add braces for the “for” statement? If you just stuck a print statement inside the existing braces, it’s in an “if”, not in the main loop.

The I6 library uses a wacky indenting style.

3

Well, that was actually not quite my problem. My problem was actually far more stupid – I actually used the same index variable (i) to iterate through the match_classes list for debugging (the numbers between the square brackets.) Now I am using k, and same as before, I am careful of the for loop and if conditional nesting (it’s no different from the C syntax :slight_smile:.

So now, the supposedly correct output is

[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 0, 0, 0, 0, 0]

(Brackets added.)

The first 12 match_classes are the classes of the compass directions, including the up above, ground, inside, and outside. The remaining 5 zeros apparently belong to rest of the objects in scope, including the selfobj.

Such a stupid mistake. :slight_smile: Anyway, I still can’t quite understand what a match_class of zero (0) means. Any idea about that?
-Nels

4

That loop shouldn’t leave any of the match_class entries as zero. I’m not sure how you got it to.

(The library already contains some debugging for that routine. Type “trace 4” at the command line.)

It’s dividing the match_list into groups, as you say, based on indistinguishability: two objects wind up in the same group if they have identical names (so the player has no way of disambiguating them). Each group gets a number from 1 up, except that if a group has more than one object, the first one’s match_class is negated.

5

Ohhhh. I see. It was a problem with the way Frotz scrolls in my terminal. :frowning:

There were 1-17 match classes after all. Thank you very much for your help!