Here’s yet another case where the compiler looks like it’s working but then goes ahead and does something absolutely insane which makes the whole thing break when you actually try to use it.
A scene has a number called priority.
Definition: a scene is questy if its priority is 1 or more.
That compiles without any issue. But what it actually compiles to is completely nonsensical. In fact, with one small exception, it can be seen as syntax sugar for something like the following:
A scene has a number called priority.
Definition: a scene is questy if the priority of it is at least 1.
Questiness relates an object (called a) to an object (called b) if the priority of a is greater than the priority of b.
The verb to be questier than means the questiness relation.
To decide what object is the questiest (D - description of objects):
... some code goes here ...
At first glance, that probably looks fine, but it’s completely wrong. A scene is not an object – it’s a kind of value. So the compiler has just defined a relation and a phrase which does not work on the type of value that it was intended to work on. You can easily see that if you actually try to use the questier than relation or the questiest phrase – you’ll get an error that it was looking for an object but you gave it a value.
But manually writing the unsugared code (with object replaced by scene, and the implementation of the phrase filled in) works perfectly, as far as I can tell (note: so far I only tested that it compiles). The only thing you lose is being able to say Some Important Quest is a questy scene – you have to say Some Important Quest is a scene with priority 1. Okay, that’s not so bad, honestly, particularly since you can just define a second adjective to get that behaviour back if you need it (and just never use the broken comparative and superlative forms of the second adjective).
It wouldn’t be terrible if the compiler just rejected that adjective definition – at least then you know it’s not going to work up front (though there’s really no reason why it can’t work). But accepting the code and then doing entirely the wrong thing without any indication is pretty bad.
As an additional note, the index seems to be incorrect on this matter. If you look in the Phrases index, you can see the implicitly-defined questiest phrase, but the implicitly-defined questiness relation is not listed in the Relations index. The verb isn’t listed in Lexicon or the Verbs index either, though I think that’s not unique to this case (a lot of multiword verbs seem to be omitted from the index).
A similar issue has been mentioned before (here), and that poster settled on the same workaround, though in their case it was the property rather than the holder of the property that was a kind of enumerated value.
By the way, here’s my actual implementation of the phrase, in case someone can see a better way to do it:
To decide what scene is the questiest (D - description of scenes):
let L be the list of D;
if L is empty:
decide on Entire Game;
let best be entry 1 of L;
remove entry 1 from L;
while L is not empty:
if entry 1 of L is questier than best:
let best be entry 1 of L;
remove entry 1 from L;
decide on best.
That if L is empty case could arguably be the reason why it was decided that this shouldn’t work for kinds of value, as there is no obvious “null” value to choose when the list is empty… but choosing the first value isn’t too bad, honestly.