Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000444Core InformTablespublic2010-11-30 08:032014-05-07 07:35
Assigned Tograham 
Platformx86OSMac OS XOS Version10.6
Product Version6F95 
Target VersionFixed in Version6L02 
Summary0000444: Inform ignores explicit typing for table columns
DescriptionWhen 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 Inform infers a subkind based on the contents of the column, the column is typed as the most restrictive kind that embraces all objects in the column. The source code provided demonstrates both cases.
Minimal Source Text To Reproduce
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.
TagsNo tags attached.
Effect(serious/mild) Game compiles but misbehaves
Attached Files

- Relationships
related to 0000446closedgraham Inform rejects kinds other than object, number, text, and indexed text in parenthetical table column typing 
related to 0001049closedgraham The phrase "X is a C listed in T" is inexplicably sexist 

-  Notes
Ron Newcomb (reporter)
2010-11-30 10:21

Possibly related:

I submitted a bug report (long before Mantis existed) that when type was inferred from Bob, the column was set to type Man rather than Person. (Likewise for Janet: Woman rather than Person.) Since a person is almost always one or the other, a special case was added to infer Person rather than Man/Woman.
capmikee (reporter)
2010-11-30 11:07

An additional quirk of this situation is that incompatible subtypes of object may be declared, but they will not match as "listed in" the table. I'm not sure why declaring an incompatible object in a table would not cause a compile-time error.


Test is a room. There is a pen in test.

Table of Conversation

Table of Specific Conversation

When play begins:
if pen is a subject listed in Table of Specific Conversation:
say "This bug has been fixed!";
say "This story compiled, but it doesn't work as expected."
EmacsUser (manager)
2010-11-30 13:07

Not matching as listed in makes sense because the generated I6 requires the right kind before it will even check for a match. On the other hand, the source you give is either accepted wrongly or miscompiled; I've split off 0000448.
graham (administrator)
2011-10-22 08:43

Fixed. The specification here is: if you write an explicit kind name, then that's the kind; otherwise Inform infers it from the initial contents, but "rounds up" to object if the result is a kind of object.

- Issue History
Date Modified Username Field Change
2010-11-30 08:03 ektemple New Issue
2010-11-30 08:07 EmacsUser Status new => confirmed
2010-11-30 09:03 jmcgrew Relationship added related to 0000446
2010-11-30 10:21 Ron Newcomb Note Added: 0000870
2010-11-30 11:07 capmikee Note Added: 0000872
2010-11-30 13:07 EmacsUser Note Added: 0000873
2011-10-22 08:43 graham Note Added: 0001422
2011-10-22 08:43 graham Status confirmed => resolved
2011-10-22 08:43 graham Resolution open => fixed
2011-10-22 08:43 graham Assigned To => graham
2012-11-15 11:54 EmacsUser Relationship added related to 0001049
2014-05-07 07:34 jmcgrew Fixed in Version => 6L02
2014-05-07 07:35 jmcgrew Status resolved => closed

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker