Conversation Rules vs 6F95

Someone discovered a problem with Conversation Rules by Eric Eve. Here’s the thread at raif: … 674ee519a8

The example included with Conversation Rules doesn’t work any more. Specifically, the subject “Jerusalem” can never be recognized. It seems that only a person can be recognized as a subject. I tried narrowing the problem down and I came up with this:

[code]Mentioning is an action applying to one visible thing. Understand “a [any thing]” as mentioning.

[There is a Table of Null Responses in “Conversation Rules” by Eric Eve which also has “yourself” in the subject column.

The addition of this table, with “yourself” in the subject column, causes Jerusalem (i.e. a thing rather than a person) to “not listed in the Table of Mentionables.”

Changing “yourself” in this table to “a person,” or changing the column header to something different to the column header in the Table of Mentionables allows Jerusalem to be “listed” again.]

Table of Null Responses

The Great Hall is a Room. Pontius Pilate is a man in the Great Hall.

Jerusalem is a thing. Caiaphas is a man.

Table of Mentionables

Check mentioning something when the noun is not a subject listed in the Table of Mentionables:
say “Pilate doesn’t have anything to say about that.” instead;

Report mentioning something:
say “Pilate tells you about [the noun].”;

Part 3 - Testing

test me with “a caiaphas/a jerusalem” [/code]

Can anyone figure out why this is happening? Should it be reported on Mantis, or is it a desirable feature that merely needs documentation?

The behaviour (buggy or not) is not specific to 6F95; at least it’s reproducible in 5Z71.

Replacing yourself in the Table of Null Responses with Great Hall triggers the check mentioning rule for both Jerusalem and Caiaphas.

Moving the table of Null Responses to after the Table of Mentionables makes mentioning suceed for both Jerusalem and Caiaphas.

It seems that being explicit about the kind of the entries of the subject column in the first table (calling it “subject (object)” ) fixes things.

Is it really that the first entry in the first table with a column that goes by a certain name determines the kind of entries of any column with the same name in any subsequent table?

In Writing with Inform section 4.15, we are told that “objects are allowed to have names clashing with other objects, or no name at all, whereas other values have to have names belonging to themselves alone”. Which suggests that table columns must be given unique names (a table column is not an object but I guess it’s a value).

Section 15.17 does say that “it is a good idea to give the columns very specific names … rather than vague names which might cause clashes elsewhere”. But in context (defining values with tables) that doesn’t give the impression of being a perfectly universal rule of syntax.

Thanks for the further clarifications, Felix.

In this case we really do want the columns to have the same names, because Conversation Rules offers a choice of tables for a single purpose. It sounds like the subject(object) clarification should work as a bugfix for Conversation Rules, but I still think this looks like a bug in Inform. If we are really using invalid values in one of these tables, there should be a compile-time error, not an unexpected runtime behavior.

What boggles my mind is that replacing “yourself” with “a person” fixes the problem. If the first table in the source is setting the datatype for that column, then Jerusalem shouldn’t be allowed later on.

(first swearing mildly)

The kernel of the bug seems to be that when you explicitly define a table-column as a subkind of object, Inform sets the datatype as simply “object” regardless of what type was specified, whereas when a subkind is inferred, the column is typed as the most restrictive kind (e.g., “person” for yourself). This demonstrates the issue:

[code]Test is a room. There is a pen in Test.

Table of Testing One
a person

Table of Testing Two

When play begins:
say “Now trying to add the pen to the explicitly typed subject column.”;
choose a blank row in the Table of Testing One;
now the subject entry is the pen;
say " It worked!";
say “Now trying to add the pen to the implicitly typed subject_ column.”;
choose a blank row in the Table of Testing Two;
now the subject_ entry is the pen.[/code]

It would be really, really nice if there were a way to see the kinds that Inform has inferred for each table column in the Index, in addition to the table names currently presented. It looks like you could create a showme type command for tables that would do that, and maybe I’ll try to figure out exactly how it could be done…


Even better if they could be in the Index.

So the apparent difference in functionality between putting the type of entries in a column in parentheses after the column name (which will give an error message if you try a subkind of objects) and that of putting it on a row below the column title (which gives no error message) is nothing but apparent!

It doesn’t look like this is possible after all. I was hoping to be able to use the same mechanism that the P60 run-time error uses to grab the table-column kind; unfortunately, this is set by the I7 compiler and thus isn’t available to authors. So, the only solution is for the functionality to be added to the Index, or to a special library debugging command that could be triggered in-game.


I’ve posted two bug reports on Mantis related to this issue: