Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000254Core InformRules and rulebookspublic2010-08-19 07:272010-10-28 00:30
ReporterPhonatacid 
Assigned Tograham 
PrioritynormalSeverityseriousReproducibilityalways
StatusclosedResolutionfixed 
Platformx86OSMac OS XOS Version10.6
Product Version6E72 
Target VersionFixed in Version6F95 
Summary0000254: RTP occurs when trying to access/modify variable of a nothing based rulebook
DescriptionWhen the system try to access a variable of a nothing based rulebook, this Run Time Problem shows up:

*** Run-time problem P31: Attempt to use a property of the 'nothing' non-object.
Minimal Source Text To Reproduce
"A test area"

There is a room.

The man prototype is a man.

[OPTION A]
The Test rules is a rulebook.

[OPTION B]
[The Test rules is a man based rulebook.]

It has a number called the test number.
It has a man called the test man.
It has some indexed text called the test text.

[OPTION A]
A Test rule (this is the bugged rule):
[OPTION B]
[Test for a man (this is the bugged rule):]
	change the test number to 1;
	[say the test number;]
	[increment the test number;]
	[say the test man;]
	[say the test text;]
	showme the test number;
		
When play begins:
	say "START[line break]";
	;
	[OPTION A]
	follow the bugged rule;
	[OPTION B]
	[follow the bugged rule for the man prototype;]
	;
	say "END[line break]";
Additional InformationNB:
---All the commented lines in the bugged rule lead to the same RTP (showme doesn't though).
---OPTION B shows that this problem doesn't exist for Rulebooks based on something (as opposed to nothing).
---This bug also concerns the "follow (R - rulebook)" phrase.
TagsNo tags attached.
Effect(serious/mild) Game compiles but misbehaves
Attached Files

- Relationships

-  Notes
(0000407)
spamalot (reporter)
2010-08-21 00:51
edited on: 2010-08-21 00:56

Here's a "more minimal" source text to reproduce the bug:

"A test area"

There is a room.

The Test rules is a rulebook.

It has a number called the test number.

A Test rule (this is the bugged rule):
	change the test number to 1;
		
When play begins: follow the bugged rule.


(0000420)
EmacsUser (manager)
2010-08-21 18:53

The bug is in the test case, not Inform.

To cite one of the problem messages, ``...a rulebook has to be formally referred to in a way making clear that it is indeed a rulebook when we give it named values, to reduce the risk of ambiguity.'' Consequently, when you write ``it'' in ``It has a number called the test number,'' you are referring to man prototype. If you were to add this line of code:

The interening man is a man.

after the declaration of the man prototype, ``it'' would mean the intervening man, and you would get a runtime problem for Option B.

Things become even more misleading in ``change the test number to 1,'' because Inform reads a property name, but there is no ``of [some object]'' phrase following it---therefore, Inform assumes that you are referring to a property of the rule's basis. Again, Option B appears to be manipulating the test number of the Test rules rulebook, but it is in fact using the test number of the man prototype.

To convey what you intended in Option A, write code like this:

- - - -
There is a room.
The man prototype is a man.

The Test rules is a rulebook.

The Test rules rulebook has a number called the test number.
The Test rules rulebook has a man called the test man.
The Test rules rulebook has some indexed text called the test text.

A Test rule (this is the bugged rule):
change the test number of the Test rules rulebook to 1;
say the test number of the Test rules rulebook;
increment the test number of the Test rules rulebook;
say the test man of the Test rules rulebook;
say the test text of the Test rules rulebook;
showme the test number of the Test rules rulebook;

When play begins:
say "START[line break]";
follow the bugged rule;
say "END[line break]";
- - - -
(0000422)
Phonatacid (reporter)
2010-08-22 04:04

In your code, the Test rules rulebook proves to be a thing, consequently i wouldn't be able to follow the Test rulebook recursively (each instance of them would share the same "Test rules rulebook" thing).

Consider the following code

-----------------------------------
"A test area"

The Test rules is a rulebook.
The Test rulebook has a number called the test number.
[OPTION A][The Test rules has a number called the test number.]
[OPTION B][It has a number called the the test number.]

A Test rule (this is the bugged rule):
    showme the test number;
    increment the test number;
    
A Test rule:
    showme the test number;

When play begins:
    follow the Test rules;
    [OPTION C][follow the bugged rule;]

There is a room.
-----------------------------------

OPTION A
You wrote 'The Test rules has a number called the test number' : but a rulebook has to be formally referred to in a way making clear that it is indeed a rulebook when we give it named values, to reduce the risk of ambiguity. So 'The every turn rulebook has a number called the accumulated bonus' is fine, but 'Every turn has a number called...' is not. (I'm insisting on the presence of the word 'rulebook' because the syntax is so close to that for giving properties to objects, and it's important to avoid mistakes here.)

OPTION B
You wrote 'It has a number called the the test number' : but I'm not sure what to make of the pronoun here, since it is unclear what previously mentioned thing is being referred to. In general, it's best only to use 'it' where it's unambiguous, and it may be worth noting that 'they' is not allowed to stand for more than one object at a time.

OPTION C
compiles but
"test number" = number: Variable unavailable for this action, activity or rulebook: internal ID number 365/0



I think my problem mainly stemmed from the "It" pronoun.

As shown by the following code, "it" refers to the previous object in the source.

-----------------------------------
"A test area"

The test man is a man.
The number between is a number that varies.
The indexed text between is an indexed text that varies.
The list between is a list of number that varies.
It has a number called the test number.

When play begins:
showme the test number of the test man;

There is a room.
-----------------------------------

IMO
either
    "It" should be able to refer to the previous value, be it an object or a non-object.
or
    "It" should lose the reference to the previous object if a value is put between. The code above would yield OPTION B's error.
(0000425)
EmacsUser (manager)
2010-08-24 12:30

Thanks for the feedback. The semantics of ``it'' have changed along similar lines before, for instance in this changelog entry:

- - - -
(h) The pronoun "it" can now mean either an object or a named value, whereas
previously it could only be an object. Thus:

Colour is a kind of value. A colour can be zesty or flat.
Mauve is a colour. It is zesty.

makes mauve a zesty colour. (The restriction to named values is because we
really don't want "it" to mean 63, or the text "frog", etc., just because
such a value has been mentioned in a previous sentence.)
- - - -

Unfortunately, I don't know whether to file this report as a bug or a feature request; I'll ask someone else to take a look.
(0000457)
jmcgrew (administrator)
2010-08-30 02:43

I'm also unsure whether it's truly a bug, but this behavior of "it" isn't what I'd expect either, so I'll err on the side of keeping it here.
(0000458)
EmacsUser (manager)
2010-08-30 08:04

Confirmed that the behavior of ``it'' is the unexpected behavior reported.
(0000579)
graham (administrator)
2010-09-22 15:14

I think the best outcome here is to make "The Test rules is a rulebook." clear the meaning of "it". (For technical reasons, "it" can only represent something about which inferences can be drawn, and rulebooks don't fall into that category.) The net effect is that these ambiguous test cases now clearly produce problem messages pointing to "it" as being misunderstood.

- Issue History
Date Modified Username Field Change
2010-08-19 07:27 Phonatacid New Issue
2010-08-21 00:51 spamalot Note Added: 0000407
2010-08-21 00:55 spamalot Note Edited: 0000407 View Revisions
2010-08-21 00:56 spamalot Note Edited: 0000407 View Revisions
2010-08-21 00:56 spamalot Note Edited: 0000407 View Revisions
2010-08-21 18:53 EmacsUser Note Added: 0000420
2010-08-21 18:53 EmacsUser Status new => feedback
2010-08-21 18:53 EmacsUser Resolution open => no change required
2010-08-21 18:53 EmacsUser Product Version => 6E72
2010-08-21 18:53 EmacsUser Steps to Reproduce Updated View Revisions
2010-08-22 04:04 Phonatacid Note Added: 0000422
2010-08-22 04:04 Phonatacid Status feedback => new
2010-08-24 12:30 EmacsUser Note Added: 0000425
2010-08-30 02:43 jmcgrew Note Added: 0000457
2010-08-30 02:43 jmcgrew Status new => acknowledged
2010-08-30 08:04 EmacsUser Note Added: 0000458
2010-08-30 08:04 EmacsUser Status acknowledged => confirmed
2010-09-22 15:14 graham Note Added: 0000579
2010-09-22 15:14 graham Status confirmed => resolved
2010-09-22 15:14 graham Resolution no change required => fixed
2010-09-22 15:14 graham Assigned To => graham
2010-10-25 21:14 jmcgrew Fixed in Version => 6F95
2010-10-28 00:30 jmcgrew Status resolved => closed


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker