Table continuation not working -- why?

Authoring Inform 7
1

I’ve been trying to implement a table continuation (extending a table in an extension), but a Problem message is being generated, and it’s not clear why. The example code is patterned after the contents of WWI 16.18 Table continuations:

"Table Continuation Problem"

Place is a room.

A zork is a kind of value.

Some zorks are defined by the Table of Zorks.

Table of Zorks
Zork ID		Zork Text
zorkA		"A"
zorkB		"B"

[normally from extension]
Table of Custom ZText
Zork ID		Zork Text
zork		text


Table of Custom ZText (continued)
Zork ID		Zork Text
zorkA		"Not A"

When play begins:
	showme the contents of the Table of Custom ZText.

The resulting Problem message (actually two of them) take the form:

Problem. In ‘Table of Custom ZText’ , column 1 (Zork ID), the entry ‘zorkA’ (row 2) is a genuine, non-blank entry: it’s a specific value. That’s fine, of course - the whole idea of a table is to contain values - but this is a column which already contains a name of a kind: ‘zork’ .
Names of kinds are only allowed at the top of otherwise blank columns: they tell me what might eventually go there. So the kind name has to go. You can replace it with a blank ‘–’, and then either let me deduce the kind by myself, working it out from the actual values in the column, or you can put the kind in brackets after the column’s name, at the top.)

The Problem message appears in both 6M62 and 10.1.2. Note that the issue can be sidestepped by defining the first table as follows:

Table of Custom ZText
Zork ID (zork)		Zork Text (text)
with 1 blank row.

but that’s not the format shown in the documentation, and my understanding was that the two formats were functionally identical.

Is there something I’m missing, or is this a compiler issue?

2 Likes
2

This doesn’t really solve your question completely, but may point others towards a solution:

It looks like any table that includes at least one column with a kind rather than an entry does not compile if you add a continuation:

"Sandbox" by Brian Rushton.

Toyroom is a room.

Table 2 - Selected Elements
Element	Symbol	Atomic number	Atomic weight
"Hydrogen"	"H"	1	a number

Table 2 - Selected Elements (continued)
Element	Symbol	Atomic number	Atomic weight
"Helium"	"He"	2	3

However, it compiles just fine if we replace ‘3’ with ‘–’.

So while I still don’t know why this behavior occurs, this is a more minimal example

1 Like
3

This compiles:

Toyroom is a room.

Table 2 - Selected Elements
Element	Symbol	Atomic number	Atomic weight (number)
"Hydrogen"	"H"	1	

Table 2 - Selected Elements (continued)
Element	Symbol	Atomic number	Atomic weight
"Helium"	"He"	2	3

this compiles:

Toyroom is a room.

Table 2 - Selected Elements
Element	Symbol	Atomic number	Atomic weight
"Hydrogen"	"H"	1	a number

Table 2 - Selected Elements (continued)
Element	Symbol	Atomic number	Atomic weight
"Helium"	"He"	2

But it seems to be internally identifying the kind of the atomic weight column as the pseudo-kind name of kind of value for the purposes of testing whether 3 is compatible with it. So it seems to be a minor bug.

1 Like
4

I’ve reconsidered this being even a minor code bug, it’s a documentation bug. The error message makes clear that Inform intends this. We just don’t get any forewarning of this. My previous speculation was wrong: it’s not confused; it just really means to exclude this case.

Names of kinds are only allowed at the top of otherwise blank columns: they tell me what might eventually go there. So the kind name has to go. You can replace it with a blank ‘–’, and then either let me deduce the kind by myself, working it out from the actual values in the column, or you can put the kind in brackets after the column’s name, at the top.

5

It took me a while to understand what you are saying, and I think I get it, but this still seems like something more than a documentation problem.

The way that I was reading the Problem message when I posted this was that its claim to understand that zorkA was a “specific value” meant that it understood zorkA to be an instance of the kind of value zork (an understanding reinforced by its mention of the zork kind of value). From what you’re saying, it’s as though the compiler is first putting together the table and its continuation as

Table of Custom ZText	[table name]
Zork ID		Zork Text	[column names]
zork		text		[column values establishing kinds/kinds of value]
zorkA		"Not A"		[column values of incompatible kinds/kinds of value]

before it tries to determine the datatypes for each column. That makes sense, but per WWI 16.8 Blank columns:

Inform is unable to work out what kind of value should go into the “atomic weight” column here, since it has no examples to guess from. We can get around this by writing in the name of a kind of value: … That top entry in the “atomic weight” column is also blank, but now Inform knows that anything put into the column in future will be a number.

So a table definition of the form:

Table of Custom ZText
Zork ID		Zork Text
zork		text

should create a table with one blank row, with the data type of the two columns set to zork and text respectively. And in fact a table with one blank row is created, and the Index shows that it has understood the types correctly:

Table of Custom ZText	2 columns x 1 row
  col 1:  Zork ID		of zorks
  col 2:  Zork Text		of texts

However, it’s not clear how to create a continuation for this table using any syntax. Is it just not possible? And if it is not possible, is that by design?

That really doesn’t seem likely, especially when the following compiles without issue:

Table of Custom ZText					[table name]
Zork ID (zork)		Zork Text (text)	[column names with kind/kind of value]
with 1 blank row.						[directive to add blank row, needed to avoid "table has no rows" problem message]


Table of Custom ZText (continued)		[table name, with continuation indicator]
Zork ID		Zork Text					[column names without kind/kind of value]
zorkA		"Not A"						[column values matching defined kind/kind of value]

I note that the Index summary of the “original” table definition of this second version (if compiled without continuation) again shows that the compiler understood the datatype assignments correctly:

Table of Custom ZText     	2 columns x 1 row (1 blank)
  col 1:  Zork ID     		of zorks
  col 2:  Zork Text     	of texts

It seems to me that, when it hits the continuation table (which is identical in both versions), the way that it reads the contents shouldn’t differ because it has been given the same specification by both versions of the original table declaration.

4 Likes