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.)
Lots of fun questions.
The only pre-processing pass is to pick up compiler options like !% FOO=1. That’s very simple parsing – it has no notion of the language syntax.
Writing a whole new language parser for the preprocessor is not in scope, as they say.
It could be a separate tool though, like Typescript is for Javascript.
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 were Typed Inform:
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.
Typed Inform was solving a different problem – it’s not what I’m thinking of here. Sorry, this is just a vague memory. Not important.
Inform 6’s syntax is ambiguous at place and it allows naming variables like keywords, amongst others.
Yep.
The proposal here is to let the library declare the article property with a type:
Property article [String] "a";
(That’s Python-style. The comment style you suggested would also work. Lots of other possibilities.)
Ignoring the question of how it’s spelled, this declaration would let the compiler type-check constant values in an article property
Object foo
with article 'word';
Warning: expected String but found Dictionary word
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.
Anyway.
But it’s not a valid program. That’s the point. It crashed the interpreter.
The difference between syntax and semantics is merely semantic, so let’s please not go too far down a rabbit hole. :)
Syntax is spelling form. Semantic is diction usage.
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.
I feel bad about that project and I should probably remove the extension from vscode marketplace it since I know of its current limitations.
I did start a total grammar rewrite for inform6 in antlr4 some time during last year where I didn’t skip the code block sections and made the grammar pretty much complete (except for the preprocessing directives) but I did nevertheless run into issues with the preprocessor anyway. It’s a pain since the design decision to put the preprocessor inside the language itself instead of having it run before independently of the parser makes writing a utility like that somewhat of a Chtulhu nightmare to get completely correct. I guess I could probably complete it if someone where to write or tweak an existing c-preprocessor to work with inform6 or add an option to the compiler to output the preprocessed code.
(I did also experiment with the output of gameinfo.dbg as an alternative but the disadvantages there is that the compiler only outputs that info to a file, not stdout and you can’t track object procedures. Otherwise it has a lot of information about the code structure and with line and character data from original source code)
Either way I think you are completely right about a making handmade parser instead of a grammar.
Best option in my opinion would be to use AST from within the compiler and have it output to stdout with a compiler option.
No need to feel bad!
I mean, I said I would make some bug reports but I never did it. (I’m more of an Inform 7 user.)
You know, I was not aware of this! I must have read it in the spec, but it never stuck in my head.
It is not true in Glulx. This is an uncomfortable behavior difference between the platforms. Oh well.
Of course, if you put a 0 as a placeholder for say a
beforeroutine
You sure you’re not thinking of -1 (NULL)? Hm, maybe they do the same thing.
…I just realized that even though the compiler doesn’t define NULL as -1, it does distinguish -1 as a special value in the obj.prop() veneer routine. Oh, what a headache.
I filed an issue for this idea at Optional type annotations · Issue #170 · DavidKinder/Inform6 · GitHub . It’s not something I’m going to tackle soon, mind you.
CA__Pr (the veneer routine responsible for performing obj.prop()) solves this on line 314 in veneer.c ( default: return x-->m;) by returning the property value as is when the value isn’t a routine or string. Additionally, If it finds the value -1, it returns false.
Yeah, so 0 and -1 behave the same: stop iterating down the property and return 0.
(But not the same as [; rfalse; ], which continues iterating down the property. This always confused me.)