"the same property seems to be being set in each of these sentences" for one sentence?

[patrick_mooney]

I’m working on a largeish piece and made some changes last night that have caused a long cascade of parsing errors. Looking back at the changes I made, I don’t see anything to trigger all of these parsing problems, and I can’t figure out what the original sin I committed is.

The first chain of parsing errors came when Inform suddenly stopped understanding declarations of the abbreviated form

There is a room called Farm. "Rows of corn, and a pig-pen at the back."

but was OK with more verbose expansions:

There is a room called Farm. The description of Farm is "Rows of corn, and a pig-pen at the back."

Well, all right: i went through and expanded the syntax for several dozen such declarations. Not a real problem.

However, the compiler is currently choking on this room, which has not yet really been written and is still essentially what it was when I exported a map from Trizbort to Inform several months ago:

Book Miscellaneous Interiors

Part Jail Cell

There is a room called Jail Cell.

An inmate is a male person in Jail Cell.
A rock is a thing in Jail Cell.

There is a door called prison door. prison door is closed and openable and locked. The prison door is south of Jail Cell and north of Reformatory Hallway. 
The description of prison door is "#FIXME".

Inform kicks this back when I try to compile:

Report on Translation: Failed
Produced by Inform 7 (build 6M62)

[…]

In Volume Game World, Book Miscellaneous Interiors, Part Jail Cell:

Problem. You wrote ‘There is a door called prison door’ : but this looks like a contradiction, because the same property seems to be being set in each of these sentences, but with a different outcome.

Problem. You wrote ‘There is a door called prison door’ : again, this looks like a contradiction.

Problems occurring in translation prevented the game from being properly created. (Correct the source text to remove these problems and click on Go once again.)

Normally, when I see this type of error message, the orange arrows jump to and highlight different lines of code; in this case, they both point to the same line.

Enabling the debugging output doesn’t get me much more:

-----------------------------------------------------
Phase IX ... Making the model world
-----------------------------------------------------

Problem PM_PropertyContradiction issued from inform7/Chapter 22/Inferences.w, line 786
Problem PM_PropertyContradiction issued from inform7/Chapter 22/Inferences.w, line 786

In Volume Game World, Book Miscellaneous Interiors, Part Jail Cell:


  >--> You wrote 'There is a door called prison door' (source text, line 854):
    but this looks like a contradiction, because the same property seems to be
    being set in each of these sentences, but with a different outcome.

Problem PM_PropertyContradiction issued from inform7/Chapter 22/Inferences.w, line 786
Problem PM_PropertyContradiction issued from inform7/Chapter 22/Inferences.w, line 786

  >--> You wrote 'There is a door called prison door' (source text, line 854):
    again, this looks like a contradiction.

This fragment compiled just fine during the previous two months, and it compiles just fine if I copy it to another blank project. Clearly, there is some other declaration interfering with compiling the statements that make up that room.

However, I can’t find what it is: in a piece of nearly 15,000 words, nothing immediately sticks out as an error when I scan through, and looking at the edits I made last night doesn’t make anything jump out at me, either. I’ve checked other things that seem like obvious checks: there are other doors with “prison” or “jail” in their name, for instance.

So I’m stumped: there’s a contradiction, but I can’t find it, and the error message from ni is pointing to the same thing twice instead of pointing to the two things it can’t reconcile.

Can anyone point me toward things I should check?

EDIT for formatting. EDIT again to correct typo.

[severedhand]

I’ve got a few suggestions at a broad level.

I’ve been in situations where I start getting seemingly bizarre errors cascading like this, and in some cases (that may be similar to yours) they’re triggered by one small formatting change I’ve made. It can be very hard to source, because the first reported error tends not to be generated at the spot where the breaking change was made.

• When I say formatting, this can include moving code between chapters/sections. Inform favours referring to Things in the current chapter of code if a reference you make in your code is at all ambiguous. The following is from 2.6 in the docs: *Finally, headings are used when working out what a name refers to. Suppose the source contains both a “four-poster bed” and also a “camp bed”, and we write something like “The pillow is on the bed.” Inform decides which bed is meant by giving priority to whichever is defined in the current section (so far), or failing that the current chapter, or current part, or current book, or finally the current volume."

So if you’re using sections, moving code from one to another can have ramifications if you’re unlucky. e.g. Tons of code starts referring to the wrong thing or kind of thing, confusing Inform, eventually leading to the compilation to fall apart.

Btw, you can protect against this, sort of, by using ‘Use unabbreviated object names.’ in your source. It turns off Inform’s assumptive behaviour I described above.

• Something else I’ve had weird problems with is using the abbreviated form of assigning initial appearances and descriptions. Personally, I’m always nervous they might refer to the wrong thing in the source if I don’t write the expanded version, but I’ve seen weird bugs where not putting a period after the end of the initial appearance or description text in some circumstances can lead to a formatting bug cascade beginning at the point I left out the period.

So, you mentioned your original

There is a room called Farm. "Rows of corn, and a pig-pen at the back."

and you already changed it to

There is a room called Farm. The description of Farm is "Rows of corn, and a pig-pen at the back."

With my paranoia, I do it the second way, and I stick another period after the second quote mark:

There is a room called Farm. The description of Farm is "Rows of corn, and a pig-pen at the back.".

• Overall, I would comb your code at the earliest point in it (in chronological order in the source) you believe you made changes. So there might be something really elementary, but hard to spot, there. Moved or reordered code, missing punctuation, malformed formatting you introduced by mistake.

What’s complicating it is, it sounds like this problem actually kicked in when you were forced to switch to unnabreviated declarations. So I suspect you introduced the problem code/formatting in the moments – or period of work – before you ran the compilation where that first happened. That’s where I’d be looking for some little formatting glitch.

Of course, it may be something weird and unrelated to formatting, but the things I’ve described are what I’d be looking at first.

-Wade

[patrick_mooney]

Thank you, Wade. You’re right: I realized when I started seeing the cascading errors that I’d already done something somewhere that was wrong, but I thought, heck, if I prune out the secondary problems, it’ll help to clarify the other half of the problem.

This turned out not to be correct: the cascade bottomed out with an error message that turned out not to be helpful. (But then, it’s not surprising that one implication of a compiler trying hard to extract meaning from many syntactically different constructions would occasionally guess wrong, and that that would make it harder to spot the where the original guess had been incorrect.)

For anyone else who stumbles across this, what I did was narrow down where the problem is by pulling out one room’s code at a time and trying to compile until I found out which room I could remove and get compilation to work. That necessarily being the location of the problem, I then performed the same operation on individual paragraphs, then sentences, in the chapter in which I was writing that room, pulling out objects and NPCs until I found which one prevented compiling.

In my case, the problem turned out to be this set of declarations:

Chapter Drinking

A thing can be potable or nonpotable. A thing is usually nonpotable. A drink is a kind of thing. A drink is always potable. Understand "drink" and "beverage" as a drink. 

A beer is a kind of drink. Understand "beer" as a beer.

The block drinking rule is not listed in any rulebook.

Inform seems not to like having “drink” defined as a class of thing, perhaps because it wants to see “drink” as a verb. Changing the word “drink” to “beverage” in the definition fixed the problem.

Weirdly, the problem didn’t crop up when I defined the class; it only cropped up when I finally instantiated a drink (er, a beverage, now) last night, with the sentence Barbara carries a drink called the martini.

In any case, those directions were very helpful in directing me where to start looking to narrow down the problem. Thank you again, Wade!

[severedhand]

I’m glad to hear you’re going again!

-Wade