Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000931Core InformKinds and type checkingpublic2012-06-11 15:112014-05-07 07:33
ReporterFuchsia tude 
Assigned Tograham 
PrioritynormalSeveritymildReproducibilityalways
StatusclosedResolutionfixed 
Platformx86OSWindowsOS Version7
Product Version6G60 
Target VersionFixed in Version6L02 
Summary0000931: Missing type checks storing values in tables
DescriptionThe attached source does not provoke runtime problem P60, even though a room is stored in a column of things.
Minimal Source Text To Reproduce
There is room.

Table of Scored Listing
output
a thing
with 30 blank rows.

When play begins:
	choose a blank row in the Table of Scored Listing;
	now the output entry is the location.
Tagswrongeffect
Effect(mild) Compiler accepts invalid code
Attached Files

- Relationships

-  Notes
(0001685)
zarf (developer)
2012-06-14 08:53

Should be a compile-time problem, in fact. "Now the output entry is 6" correctly throws an error at compile-time.

The compiler appears to be creating a column of objects rather than a column of things. Might be related to bug 690.

Defining the column with "output (thing)" rather than "output/thing" on two lines doesn't compile at all. I find that weird.
(0001686)
NYKevin (reporter)
2012-06-14 11:26

>Defining the column with "output (thing)" rather than "output/thing" on two lines doesn't compile at all. I find that weird.

I believe that's only allowed for "(indexed text)" as an escape-hatch for type inference, and not for general use.

*tries it*

It looks like that's only half right. You cannot use any kinds of object, except, bizarrely enough, for "(object)" itself. But other kinds of value are fine, unless they involve kinds of objects (e.g. "(list of things)" doesn't work but "(list of numbers)" is fine; again, "(list of objects)" is fine). That's rather wacky behavior, IMHO.
(0002419)
graham (administrator)
2014-02-01 03:52

Fixed. The reason this happened was that Inform infers the kind of a table column from its entries in an intentionally weak way, in which all kinds of object are weakened to "object". This is so that if a column has three entries reading, say, Peter, Paul and Luke, then Inform won't throw RTPs if the author then changes an entry to Mary. Peter, Paul and Luke are all of kind "men", but that could be just a coincidence about the initial state of the table.

But you can of course override this by explicitly giving the kind of the column, by writing

Table of Scored Listing
output (a man)
...

and the bug here was that the kind given in the first row was being subjected to the weakening rule as if it were a constant.

- Issue History
Date Modified Username Field Change
2012-06-11 15:11 EmacsUser New Issue
2012-06-11 15:11 EmacsUser Tag Attached: wrongeffect
2012-06-11 15:11 EmacsUser Reporter EmacsUser => Fuchsia tude
2012-06-11 15:11 EmacsUser Status new => confirmed
2012-06-14 08:53 zarf Note Added: 0001685
2012-06-14 11:26 NYKevin Note Added: 0001686
2014-02-01 03:52 graham Note Added: 0002419
2014-02-01 03:52 graham Status confirmed => resolved
2014-02-01 03:52 graham Resolution open => fixed
2014-02-01 03:52 graham Assigned To => graham
2014-05-07 07:32 jmcgrew Fixed in Version => 6L02
2014-05-07 07:33 jmcgrew Status resolved => closed


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker