-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
give
statement with arbitrary expression produces invalid story file
#171
Comments
(In the line |
Whoops, hang on, I'm wrong about what happened. The line Yeah, it's not obvious how to even detect this. We could warn on Maybe the call syntax |
This is not a rule at all, I'm afraid. There are an infinite number of ways to produce an invalid story file. Calling |
Ah, I didn't know it was possible to have a In that case, yeah, the syntax is ambiguous but the compiler isn't wrong either, so I guess it's not a bug after all. (Although I would have thought interpreters would display an error message in the lines of "tried to call something that's not a routine".) I suppose that, as you said, it should be possible to type-check routine calls, but that's not extremely important either. |
#172 is the routine-call type check.
Of course this warning only appears when |
The compiler accepts arbitrary expressions for attributes in the
give
statement. However, it sometimes produces an invalid story file in that case, without emitting an error or a warning.For example, the following works, giving the attribute with ID 2 to the room:
(Compiled with
inform6 -~S~D -c test.inf
)However, if we replace
1 + 1
with a parenthesised expression such as(1 + 1)
or even(locked)
, Quixe will show this error message when running the story : "Error: Unknown opcode #0 at pc=201". Gargoyle (git) also complains with a different error message: "Fatal error: too many (48) locals at 0x14 (pc = 0x512)".On one hand, that situation shouldn't happen often since authors aren't likely to use expression in that place. On the other hand, the compiler should never produce an invalid file without complaining.
I'm not sure if accepting arbitrary expressions in that place is a good idea since it leads to ambiguous syntax. But I'm not really sure what should be done.
The text was updated successfully, but these errors were encountered: