I recently struck an issue where Windows Frotz crashed partway through printing the contents of a container. Unfortunately, I didn’t take note of the actual error, but it was indicating that a routine did not exist or could not be run or something like that.
After much hair tearing, I realised that I had: article 'some',
instead of: article "some",
In other words, single quotes instead of double quotes. This is easy to miss amongst hundreds of lines of source code.
(For what it’s worth, this was one of those situations where the object was singular, so the pluralname attribute wasn’t appropriate, but the article was “some”.)
Is it possible for a future version of the compiler to detect this error at compilation time?
There’s no way for the compiler to detect this because there’s no way to declare what kind of value a property is supposed to hold. It’s legal for properties to hold dict words. In the standard library, only the name property contains dict words, but there are library extensions that define others.
In fact you could define a property which contains either a string or dict word, and check its value before using it to handle it properly. (This is not practical in Z-code, because Z-code dict word values aren’t distinguishable. Works fine in Glulx though.)
(Footnote: the compiler does know the type of the name property, because that one is hard-wired in the compiler. So you can write with name "lamp" and the compiler will figure out that you meant to use single quotes. All other properties are defined by the library, however.)
I doo agree stronger typed inform would have been really handy sometimes. I’ve only recently started a Inform 6 project again and the times i’ve got numbers and strings and objects confused is astounding (doing nothing very complex). Something like Python/mypy optional type annotations would be awesome. Then again, this is the real retro experience
Optional type annotations are an interesting idea.
The compiler already does better type-checking (warnings, not errors) for operators like . and has. (E.g., for the expression (O has A), O should be an object and A should be an attribute.)
Doing the same type-checking for global variables and properties wouldn’t be hard. The hard part is extending the syntax for declaring these things with type annotations.
Is there a formal definition of the syntax anywhere? If there is, you could do a pre-processing pass where it checks the syntax prior to compilation. I know the compilation does some of that anyway, but the pre-processor could detect the things that the compiler doesn’t currently detect.
The other fun part is that lots of library properties have an implicit type of “string or routine”.
Is nothing or 0 always permitted? Or can you declare that as part of the type? What about sentinel values like -1? (The library defines a special value NULL = -1 but the compiler doesn’t know about that.)
My estimation is that writing a whole new language processor would be about 12.75 times as much work as adding type annotations to the existing compiler.
This number arrived at by the highly scientific method of looking at the problem and saying “you’ve got to be kidding me”.
(Didn’t vaporware or somebody start doing this once?)
Aren’t there tools where you can feed it a text file and a formal syntax definition (defined in another file) and it parses the file and spits out any syntax errors?
There’s also a language server for Inform 6, although last time I checked there were some bugs.
I suppose it would be possible to add non-obtrusive type annotations with special comments, like JSDoc, but it will have to be well thought out, as said above. Something like:
!! @type Number
Global score = 0;
I’m also currently writing an Inform 6 grammar to enable syntax highlighting in Borogove, because that’s what CodeMirror, the code editor it uses, wants. (No error checking, only highlighting) And it’s a pain: Inform 6’s syntax is ambiguous at place and it allows naming variables like keywords, amongst others. So my grammar will sometimes be approximate, as long the highlighting it gives is correct.
I believe Inform 6 works better with a hand-written parser than a grammar/syntax definition, but I might be wrong.
It should be possible, but your original question was a semantic analysis, not a syntax one, so it wouldn’t solve preventing putting a dictionary word in the article property.
It actually is a syntax issue. A dictionary word is defined using single quotes, but the article property requires a string, which is defined using double quotes.
I disagree. Syntax-wise, it’s a valid program. It’s absolutely legal to put a dictionary word in a property (which happens to be named article here).
The compiler/analyser would have to know that the article property is supposed to hold a string, and that means we go into semantic analysis territory.
So if you feed the hypothetical tool (which actually exist, it’s the compiler) a formal syntax definition and your source, it won’t complain. (Except if you hardcode article to be a dict word in the syntax definition, but I don’t think it would be a good idea.)
That’s partly solved if types annotations are added to the compiler or something else, but i still think there’ll be a bit of semantic analysis.
As I’m sure you’re aware, 0 is considered a valid routine address in Z-code, and calling it yields a return value of 1 without actually executing any code or examining the contents of address 0. Is this the case in Glulx as well?
However, Inform doesn’t consider 0 to belong to the Routine class, so testing if it’s a routine doesn’t reveal that it can be called as one.
Of course, if you put a 0 as a placeholder for say a before routine, it won’t be called but will instead be considered the same as if the object didn’t provide the property at all.
