You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some ancient version of Inform imagined it was a good idea to quote your local variables:
[ MyTest "x";
return x+1;
];
You can use this to define local variables which are not symbols, which is entirely useless as far as I can tell -- you can't use them in expressions or statements.
[ MyTest "!" "x+1";
return x+1; ! error because there is no variable "x"
];
I would like to get rid of this pointless feature. In theory this might break some previously-valid code, like the first example above, but I bet it doesn't.
The text was updated successfully, but these errors were encountered:
Ignoring quotes is a general behavior of get_next_token() when dont_enter_into_symbol_table is true. Which means that this inconsistency turns up in lots of places! All of the following compile without error:
I think that's everywhere we parse a symbol with dont_enter_into_symbol_table set. (There's places where we use it but don't parse symbols, e.g., code that is #if'd out.)
It should be okay to reject quoted symbols in all of these cases. Except maybe the Strings directive? But that's explicitly deprecated now, with a warning.
Conclusion: I am going to remove this general behavior -- get_next_token() should distinguish between quoted strings and bare-strings. All the above cases will only accept bare-strings.
Some ancient version of Inform imagined it was a good idea to quote your local variables:
You can use this to define local variables which are not symbols, which is entirely useless as far as I can tell -- you can't use them in expressions or statements.
I would like to get rid of this pointless feature. In theory this might break some previously-valid code, like the first example above, but I bet it doesn't.
The text was updated successfully, but these errors were encountered: