I7: Different Error Messages with Is A Kind Of Construct

So let’s say I have this simple source:

A location is a kind of room.

There is a location called the Drawbridge.

That gets me this error:

When I change the code to be this:

A location is a kind of room.

The Drawbridge is a location.

I get this error:

Neither message tells me why this isn’t working and I’m not sure why I’m getting different error messages anyway.

If I try this:

An outdoor location is a kind of room.

The Drawbridge is an outdoor location.

that works.

So it seems like “location” is an internal word that Inform 7 uses perhaps. I look up that phrase in the documentation and eventually find that may be the case. But I wanted to make sure that this is why I was not only getting an error, but getting two different errors based on a slight difference in the assertion of the room.

I’m wondering if it would be possible for Inform to just tell me that I’m using a reserved word. In this case, when I used “outdoor location” it was fine but that means Inform could probably (maybe?) have flagged the fact that I was using “location” which is a reserved word. The only thing that made me question this was the fact of two different error messages for what seems to be the same issue. As an Inform developer, this would worry me. I would expect the assertion

A location is a kind of room.

to generate a compiler error, if I’m understanding why Inform won’t let me use the previous source text.

This is a namespace issue. The “location” is a global variable that holds the name of the room where the player is, so it can’t be used to name a new kind of room.


That sounds like a great exception message that Inform could generate to let you know exactly that. :slight_smile: I concede this might also be in the manual in a place that I missed it and upon looking at some examples I do see that “location” is used. As a developer, I’d still be worried about two different error messages if only because it makes how the system is doing things a bit more opaque.

Inform should never allow the sentence “A location is a kind of room” at all, and should probably trigger a message that indicates that Inform already has a definition of “location” and that this incompatible.

However, I don’t think there’s an issue with the use of two different messages. These result from two slightly different interpretations of your code, and that’s really unavoidable. Both of them are telling you what’s wrong, and relatively clearly: they both imply that Inform is not reading “location” as a kind, and one of them specifically says that Inform is reading “location” as a thing. These messages could definitely be clearer, though, or at least have more expository text tacked on, but I think they’re doing their jobs. A quick search of the docs using the IDE would have led you straight to the library’s use of “location”–it’s probably used at least a hundred times in the text and sample code; there’s also the somewhat out of date syntax summary, which is a handy reference for this kind of thing.

You should post this as an error-message issue at the bug-tracking site.


But my code is saying the same thing in both cases isn’t it? That should imply a single interpretation. Clearly not.

Error messages shouldn’t be “relatively” clear nor should they imply. They should assert. The one messages says “‘There is a location called the Drawbridge’ : but I can only make ‘a something called whatever’ when the something is a kind I know, possibly qualified with adjectives”

As far as I could tell from my source, ‘location’ was a kind it knew since I defined it before the assertion.

The other message is “You wrote ‘The Drawbridge is a location’ : but this seems to say that a thing is a value, like saying ‘the chair is 10’.”

It says it “seems to say” this but not necessarily that this was the case. Once you know about location and value, of course, then it’s clear. But, on the other hand, once you know it, you probably wouldn’t make that mistake in the first place. You also said “one of them specifically says that Inform is reading ‘location’ as a thing” but based on the above error, I actually thought Inform was telling me location was a value, not a thing. So this is much clearer to you than me in that case.

Agreed. And that’s what I ultimately did. But again it just seemed odd to me how Inform was acting. As far as writing a bug, I’d hate to write a bug if Inform is “telling [me] what’s wrong, and relatively clearly.” :slight_smile:

People who are willing to spill the verbiage about minor issues on this forum but aren’t willing to file bug reports get on my nerves–especially when they refer to themselves as developers who are “worried” about the software. This post is probably touchier than it ought to be, especially since I didn’t bother to read your initial post all the way through, but just to be clear:

My post confirmed two problems you mentioned, both of which I would think you’d have agreed with:

  1. Inform should not allow the name of an already existing global variable to be used as a kind.
  2. The two messages that you did receive, while they are appropriate to the context, could be worded much more clearly (I said, “These messages could definitely be clearer, though, or at least have more expository text tacked on… You should post this as an error-message issue at the bug-tracking site”).

While I disagreed with your contention that Inform should have given you the same message for both of the constructs you presented, I certainly did not argue that the messages you received were well worded–just that they were not spurious.

Now, I didn’t read your original post all the way through, so I missed that you had actually worked out what the error was before posting, and that your question really was limited to why there are two messages for what you consider to be a single assertion. So I should have just given you this explanation to begin with:

In the case of “There is a location called the Drawbridge”, the grammar forces Inform to read the assertion as an attempt to define a new object of a given kind, but it’s fails because it can’t read “location” as a kind because the global variable is taking precedence. In the other case, “The Drawbridge is a location”, you are using a much more generic form; there is no clear indication in the grammar of the assertion that “location” is intended to be a kind. It’s just as likely, for example, that you are trying to store the Drawbridge in the location variable. So, Inform reads this an illegal attempt to set a thing to an undetermined value. (This is the message that I think is the most unclear, just because Inform doesn’t say which is the “thing” and which is the undetermined “value”; it would also be nice if it spelled out the kinds of situations in which the error might arise, as the more recently added messages tend to do.)

Again, these are issues that could easily be fixed. You indicate that you’re not inclined to file reports for them, and I guess that’s your business, but please don’t pretend that it’s because I talked you out of it…


I believe that the point he’s trying to make is that he doesn’t want to file a bug report if the compiler is clearly telling him what the problem is, yet he isn’t understanding what the compiler is telling him. You reinforced his point that there is an issue with the verbiage of errors. It’s also been discussed (repeatedly, if I recall) on the forums before. The problem with Inform compiler errors is that they try to be adaptive to multiple situations while simultaneously applying to the single situation that you’re receiving the error about while also trying to be human readable.

Thus, to draw on my own experience:

Parse error: syntax error, unexpected $end in Z:\...\index.php on line 275

Inform delivers the same message in something along the following format:

Pardon me, sir, but I encountered a bit of text somewhere around the general vicinity of The Bathroom where I believe you sincerely intended to intimate the closure of an assertion. While you told me, "If one is taking a dump and is out of toilet paper", I expected to see "The grass is blue on the left side of the bubble gum tree". That's like saying "a grasshopper is a soda can" which of course doesn't make any damn sense."

I love Inform 7. But the error messages have been rubbing the cat the wrong way for a lot of people for a long time, from what I can tell. Everyone doesn’t have Dr. Temple glasses and can see through all the verbiage of these error message.

In my PHP example above, the error SHOULD read:

That closing bracket generates the “unexpected end” at the bottom of the file. But since you don’t know where you left it out, you’re searching through (sometimes) pages and pages of code trying to find the missing bracket. While Inform will at least point you in the right general vicinity, the error messages are unforgivable. I don’t need a polite explanation of “maybe this is what I meant” over a friendly game of checkers. I need to know exactly what my error is, what line it’s on and why it’s a problem. (No Oxford Comma here, thank you.)

I realize that the NATURE of Inform 7 may make this approach both contradictory and cumbersome.

I’m just saying, we don’t all understand the error messages that we’re being given, because they don’t look like error messages. They look like someone trying to console us over the death of a beloved pet. I think bukayeva was saying the same thing. “Just because I don’t get it doesn’t mean it’s a bug. You obviously understand it, so it’s probably working as designed and I still have a little more to learn.”

[Edited to remove some condescension that I sincerely didn’t intend to be there.]

And yes I know that my PHP example isn’t a direct analogy. But it was the quickest error I could generate with the least helpful error response.

While I regret pretty much everything I’ve done in this thread, I don’t really buy your interpretation; bukayeva understood the messages well enough to diagnose the issue, and he also sketched what he thought was wrong with each of the individual messages (I agree with assessment). So I don’t think that he was saying what you attribute to him.

But maybe he was. A bit of context is missing that would help clarify why I recommended–and still recommend–reporting issues of error message quality on the bug tracker. The Inform developers take error messages very seriously as a feature of the language. That’s why they are more useful and better targeted than the PHP message you mentioned (please don’t even mention Javascript!). As part of that dedication to error messages, there is a category specifically for reporting unclear or unhelpful messages. (Actually, I’m pretty sure that there used to be more than one place to report problems with built-in error messages, but one of the categories I remember doesn’t seem to be available any longer.) Anyway, here’s a recent report from me:


That report is pretty much the same kind of issue–a message that is deployed at the right time and for the right reason, but isn’t as helpful as it could be–taken to a ridiculous extreme (click through and you’ll see what I mean).

So, the next time you’re reading an error message and wish you had your Dr. Temple glasses (!–I wonder what the condescending stuff you took out looked like! :slight_smile: ), please consider filing a report.


Are you thinking of “Core Inform --> (cosmetic) error message is badly worded”? That’s still there – I actually looked it up when I was preparing a response to this post, which basically was going to say the same thing you did. One thing that confused me about the bugtracker for a while is that you get a whole different menu of possible bugs if you use the drop-down menu for “Project” in the upper-right, in addition to the drop-down menu for “category.” I misfiled at least one report for this reason, and also wound up e-mailing Emily about one of the examples because I didn’t realize that I could select the examples in “Project” (well, “documentation, examples, and web site” or some such).

In any case, “Location is a kind of room” is definitely a bug – the compiler is accepting invalid code, as you’ll never be able to use “location” as a kind – and should be reported, even if one is reluctant to report the compiler messages for fear of being told that it’s a PEBKAC (though in that case one should not be such a shrinking violet, anyway).

Thanks, that very well might be what I was thinking of. Either way, the discussion in another report in the section I pointed to seems to indicate that the Documentation section is the more appropriate place, rather than using the Core Inform “error message is badly worded” flag; that discussion is here.


Hmmmm, it seems to me that that discussion actually indicates that it filing it against the Documentation is better than filing it against the front-end applications, but leaves it open as to whether other error messages should be filed against Core Inform.

That’s also a valid interpretation. I guess that it probably doesn’t matter too much–Graham’s response to the discussion was simply “Fixed”!

I’m not saying he was or he wasn’t. I’m saying that’s what it seemed like to me, as I’ve had that exact internal dialog over error messages countless times.

Wouldn’t dream of it. I put JS right up there with the Oxford Comma.

Hah. The “condescending” stuff wasn’t intended to be, but in reading my post again after I submitted it, I decided that it could certainly be interpreted that way. This statement wasn’t intended to be condescending either, but complimentary. I struggle with almost every single error message that Inform jabs into my eye socket. Most of the time I can’t figure them out at all and just hack at the source until it doesn’t give me error messages anymore. (Which generally means it isn’t doing what I had originally wanted it to, either.) Whereas you, and several others on this forum, seem to glance over at the error, nod your head sagely to an old friend and set about making amends.

That’s all.