I7: Limit on declarations for kinds of value?

As I did some more work on my project yesterday, I seem to have encountered another stumbling block with no readily identifiable cause. This problem seems to be that I have run up against some sort of limit on declaring new kinds of value. I looked through the I7/5Z71 documentation, including all the various “Release Notes” sections, and could not find any reference to this issue (although I might have missed something–the print in those Release Note sections is pretty small and my vision isn’t what it used to be). I also did a few on-line searches, but didn’t turn up anything that seemed directly relevant to my problem.

Basically the situation is that I have a project file that compiles and works fine; however, if I add one additional declaration in the form of:

A is a kind of value. The as are b and c.

the project won’t compile; I instead get the mysterious and dreaded:

message of doom.

I’ve noticed before that when Inform throws out an error message like this, sometimes helpful information can be deduced from any additional messages that appear in the “Progress” pane of the “Errors” tab, but in this case beyond the usual “I’ve read your source text, I’ve also read the Standard Rules, etc” the only thing listed there is “Compiler finished with code A.”.

To frame the issue in more concrete terms, I searched my source text for the phrase “kind of value” and found that I have 48 statements declaring a kind of value using the format “A is a kind of value.” Some of the values are fairly simple, like:

Phenomenal is a kind of value. The phenomenals are tangible and intangible.

while others are a bit more complex, like:

Color is a kind of value. The colors are clear, white, grey, black, red, pink, green, blue, yellow, orange, purple, brown, gold, silver, copper-colored, brass-colored, and nocolor.

Any attempt to add an additional kind of value using what would be statement #49 in this format causes the compile process to fail as noted above. I tried using a few different silly phrases, such as:

Tetron is a kind value. The tetrons are mestral and destral.

or

Qrstuv is a kind of value. The Qrstuvs are defgh and ijklm.

just to be sure I wasn’t running into one of those hidden variable-name conflicts with the Standard Rules or any extensions, but it didn’t matter–so the problem is definitely in trying to add any additional statement defining a new value, regardless of content, using a statement in the format “A is a kind of value.”

I’m not able to quickly say what the total number of variables in use are if, in addition to statements such as “A is a kind of value” one were to also include statements such as “A thing can be x or y. A thing is usually x.” or “The car has a number called mpg,” although if anyone thinks it’s relevant I guess I could try to go through and count all such statements (in the particular version of the project I was working with I’m at about 75000 words, well over ninety percent of which is composed of rather dense rules as opposed to easy-to-scan room/item descriptions).

An additional twist on the problem is that while naming a new value using the phrase “A is a kind of value” causes the compiler to fail, naming a new value in a different way/format, such as:

The pencil has a number called timesused. Timesused is usually 1.

is accepted, and the project compiles and works fine with the new value properly assigned.

In my on-line research of the problem, I found a few older references of people who encountered “error code 10,” but none of the discussions seemed at all relevant to this matter. While I’d of course be very happy if anyone could say immediately what the problem is, I would also be quite content if anyone could direct me to any resource or documentation that either discusses what is implied by cryptic statements such as “The error code was 10” and “Compiler finished with code A”, or else mentions any limits on declaring kinds of value.

Thanks in advance for any advice on this matter.

Well, there’s definitely not an upper limit of 48 kinds of value. I just checked by creating a game with 50 of them.

Have you posted this on r.a.i-f yet? If not, you may want to do so. It could well be a bug in the compiler, but it’s not something I know how to diagnose.

–JA

Hmm. I got 50 to work as well, however w/ 51 KOVs the i6 compiler crashes for me. Note that this is a different error than the one Endosphere describes. It’s the one that begins with:

Endosphere: Do you have any code in the form of “the object is either foo, bar or bah” (as described in ch 4.10. Conditions of things – for example “The cask is either customs sealed, liable to tax or stolen goods.”)? This creates a new kind of value called “object condition” (“cask condition” in the example) and would therefore count towards the overall total of KOVs.

It doesn’t explain the problem, but it might help narrow it down.

Could it be something to do with the names you’ve used for that specific value? Have you tried creating a project with just that value to see if you still get the error?

If I understand correctly, the OP’s got a project that compiles fine until one more new KOV is added, regardless of the name given or the number of different values of the new kind.

Unfortunately, the more I look into it, the less sense it makes. This from Graham’s announcement for build 4K40(Jan 23 2007):

This is almost certainly a bug of some sort, but I’m not sure how to even begin to track it down.

EDIT: I just posted this issue on raif. I’m sure someone will be curious enough to jump in. :slight_smile:

Thanks to everyone for the responses. I spent some more time looking into the problem, and wanted to update my findings.

@Jim Aikin
Thanks for trying to duplicate the issue. I’ve found that Skinny Mike seems to have found the key to the whole thing and that both you and I fell one kind of value short in our diagnoses, but I definitely appreciate the time you took to try constructing your own example.

@Emerald
That’s a good guess, and was my first thought as well. I tried a few different ways of iterating the new value, though, and it didn’t make a difference. Thanks nonetheless for your input.

@Skinny Mike
I think you’ve successfully diagnosed the general issue, and kudos to you for doing so much more accurately than I was able to in my original post. The problem indeed is that when fifty kinds of value are defined, defining a 51st new kind of value using the phrase “A is a kind of value” causes the project to fail the compile process. The aspect I had overlooked (and frankly would have never thought of on my own) was:

I went through my code more carefully after reading your statement, and found that I have:

47 statements in the format “A is a kind of value” in my source text;
1 statement in the format “A is a kind of value” in an extension I’m using;
2 statements in the format “A thing can be…” that present more than two options (e.g. “A thing can be soaked, wet, or dry (this is the dampness property).”)

for a total of fifty declared kinds of value. This means, as you noted, that my real problem is in trying to declare a 51st kind of value (which breaks the compiler).

Although a few of my declarations for kinds of value have only two options (like the phenomenality example shown above), most have more than that (the largest is the color example shown above, with 17 options). However, I think we can say that since you and Jim both constructed examples using only two options in each value, the number of options in any particular value has little bearing on the issue.

I thought your comment that you got a different error message was very interesting, so I tried a further experiment. I made a small sample file by copying and pasting all 49 declarations of kinds of value in my source text, plus the 1 declaration from the extension used therein, and added a single room (since a room is necessary for a project to compile). The smaller test compiled fine. I then added one additional declaration of a kind of value in the format:

Tetron is a kind of value. The tetrons are mestral and destral.

The project refused to compile, with the exact same error message I reported in my original post (error code 10, compiler finished with code A), as opposed to the error message you got. To be thorough, I deleted the “tetron” declaration and restated it like so:

A thing can be mestral or destral. A thing is usually destral.

The small project compiled fine with no errors in this second case.

One of my thoughts on the overall design of my larger project was that I would generally try to use “A is a kind of value” declarations unless a value was truly intended to apply to every possible instance of a generic “thing,” and that by avoiding unnecessary statements like “A thing can be x or y” when x or y are conditions that would only be referenced in some cases for some things I would save some resources (by not storing dozens of irrelevant values for every possible thing). I guess that now seems like it may not work out, but while making the smaller test project I noticed some of my value declarations are either/or conditions (i.e. the extension or phenomenality value mentioned above, which definitely applies to every possible “thing”) and could be successfully restated as “A thing is x or y,” which will free up a few apparently limited kind of value slots for me to use in the immediate future. I was also relieved that no one immediately pointed out anywhere in the documentation that says anything like “You can only have 50 declarations of kind of value,” that I had overlooked.

In summary, thank you very much for your concise diagnosis of the problem. Hopefully an Inform guru will ride in a white horse and offer us some suggestions for fixing this issue now that it is properly defined.

I would also still be interested in looking at any resource or documentation anyone knows about that explains what is meant by statements such as “error code 10” or “compiler finished with code A.”

Thanks again to everyone for the comments.

A code 10 means that the compiler has failed for reasons that it doesn’t know how to explain (no problem message) and that probably have to do with data-typing. In other words, the “Translation failed…” message is already telling you everything it knows about error code 10. The bit about “code A” I can’t explain myself, and I suspect it is only meaningful to Graham.

What you can do about this:

a) report the bug to Graham, using the simplest possible example code;
b) in the meantime, trim a bit (as you yourself suggest) so that you’re not using kind of value as often.

Endosphere,

I’ve sent off a bug report to Graham explaining the issue with sample code (as well as links to this thread and the one on raif). I still encourage you to do the same as any additional data points might prove helpful. The reporting form is somewhere in the Inform package (I forget where) and also here: http://inform7.com/contribute/BugReport.txt

Just to clarify, Jim and I were able replicate your crash (albeit w/ a different error message than yours) using different code. I used three values per KOV and he used two. In both cases the error occurs after exceeding 50 KOVs. So far, no one else has jumped in over at raif, but the thread is here for your reference. I’m still curious as to why your error message is different than mine and Jim’s, though. I’ve been going on the assumption that you’re using the latest build (5z71).

I’m not sure, but I think that there’s more overhead associated with the creation of a new KOV then a new either/or property (which IIRC gets compiled as an i6 attribute), so the above strategy might not save you any resources anyway. At any rate, you can avoid giving things superfluous properties by creating new kinds and assigning them the needed properties. Since properties can be assigned both to kinds and individual objects, you don’t need to worry too much about a kind hierarchy limiting you later. (For example, even though doors can be open or closed, we can still create a new kind or even a single object – like an umbrella – which provides that property.)

@emshort

Thanks. I filled out a bug reporting form and sent it in.

@Skinny Mike

Thanks for putting the time in with me on this problem and for reposting the issue over at the other forum.

I don’t doubt you on that at all as you’re a lot more knowledgeable about these things than I am, and you’re right of course that using kinds of things helps. The idea that it’s more efficient to assign uneeded properties to things than attempt to assign them only when needed is counterintuitive to me, but it is what it is I guess.

@ Endosphere and anyone following this thread:

Graham sent me (and Jim) an email this morning verifying that this is indeed a bug that crept into the last build (5z71) and has been removed in the upcoming release. A new test case has also been added to the test suite to prevent this bug from reappearing in future builds. Before anyone asks, he did not mention when the new build is coming out, but in my experience, when you start getting bug reports back, the team is coming down the home stretch. :smiley:

Also, I generally don’t share the contents of private emails without asking first, but I figured in this case it would be ok. Apologies to all involved if it is not.