Confusing error message when "to" is used as an undeclared variable about inform6

[erkyrath]

Shorter example:

[ Main; ];

[ LanguageNumber n;
    if (n == 0)    { print "zero"; rfalse; }
    if (n < 0)     { print "minus "; n = -n; }
    switch (n) {
      1:    print "one";
      19:   print "nineteen";
      20 to 99: switch (n/10) {
        2:  print "twenty";
        3:  print "thirty";
        4:  print "forty";
        5:  print "fifty";
        6:  print "sixty";
        7:  print "seventy";
        8:  print "eighty";
        9:  print "ninety";
        }
        if (n%10 ~= 0) print "-", (LanguageNumber) n%10;
    }
];

[ TestFunc;
	return to;
];

line 9: Error: No such constant as "to"

The "to" in the switch statement seems to create a symbol reference, even though it should be a keyword at that point.

[erkyrath]

Also happens with the keywords on, off (in font on/off) and bold, underline, roman, reverse, fixed (in the style... statement). All of these are from misc_keywords[].

Also label names, when used as a value in a different function. (If you use a label as a value within a function, the compiler correctly complaints "Label name used as value".)

[erkyrath]

Well, this turns out to be kind of a pain. You'd think the answer would be to go into states.c and do something like this:

             misc_keywords.enabled = TRUE;
             dont_enter_into_symbol_table=TRUE;
             get_next_token();
             misc_keywords.enabled = FALSE;
             dont_enter_into_symbol_table=FALSE;

But this doesn't help, because get_next_token() reads a token ahead. By the time you set the flag, the "underline" token (or whatever) has been parsed.

In fact there are quite a few places in the code that look like

             misc_keywords.enabled = TRUE;
             get_next_token();
             misc_keywords.enabled = FALSE;

...and I'm pretty sure they don't work. This may be a long-standing bug, although I don't know if it causes other problems. (EDIT: I am wrong; it's not a bug. See next comment.)

[erkyrath]

Okay, right. The "lexical context" feature of lexer.c is meant to fix the general problem. get_next_token() will reinterpret a symbol if the current enabled keywords don't match where we were when the symbol was ahead-read.

However, as noted at lexer.c:587, the lexical context doesn't include the dont_enter_into_symbol_table flag. There's no way to reinterpret a symbol into a keyword -- that would require deleting it from the symbol table.

The upshot is that this isn't fixable in a nice way without rethinking the whole lexer loop.