Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000628Core InformPhrases and functional programmingpublic2011-03-26 09:272014-05-07 07:34
ReporterFuchsia tude 
Assigned Tograham 
PrioritynormalSeveritycosmeticReproducibilityalways
StatusclosedResolutionfixed 
Platformx86OSWindowsOS Version7
Product Version6G60 
Target VersionFixed in Version6L02 
Summary0000628: Compiler refuses complex Every turn rule and misidentifies the line to jump to
DescriptionThe error message claims that "the switched on handheld" may not be specific enough to identify which object is being referred to, but there's no other handheld in the game! The problem seems to be that the thing in the phrase is identified by an adjective, and that the phrase also references a member variable of that thing. Commenting out the adjective compiles properly, for example.

The error message also incorrectly links to the next "Every turn" rule in the source, rather than the correct one.
Minimal Source Text To Reproduce
The Living Room is a room.

	The handheld radio is a wearable device in the Living Room.  It has a number called message.
			
		Every turn when the message of the switched on handheld is 0: say "The radio plays smooth jazz."
	
	
There are some eggshell fragments. They have a number called hatch count.
		
		Every turn while the hatch count of the fragments is positive: say "'Scritch scritch.'"
Additional InformationThis is the report produced by Inform 7 (build 6G60) on its most recent run through:


Problem. In the sentence 'Every turn while the hatch count of the fragments is positive' , it looks as if you intend 'the message of the broken handheld' to be a property, but 'broken handheld' is not specific enough about who or what the owner is.

 Sometimes this mistake is made because Inform mostly doesn't understand the English language habit of referring to something indefinite by a common noun - for instance, writing 'change the carrying capacity of the container to 10' throws Inform because it doesn't understand that 'the container' means one which has been discussed recently.

 See the manual: 4.8 > New value properties



--------------------------------------------------------------------------------

Problem. In the sentence 'Every turn while the hatch count of the fragments is positive' , it looks as if you intend 'the message of the broken handheld' to be a property, but 'broken handheld' is not specific enough about who or what the owner is.

 Sometimes this mistake is made because Inform mostly doesn't understand the English language habit of referring to something indefinite by a common noun - for instance, writing 'change the carrying capacity of the container to 10' throws Inform because it doesn't understand that 'the container' means one which has been discussed recently.
 
TagsNo tags attached.
Effect(cosmetic) Error message is badly worded
Attached Files

- Relationships

-  Notes
(0001111)
jmcgrew (administrator)
2011-03-27 14:11

I believe this code is invalid. You can use "switched on handheld" to mean "the handheld (but only if it's switched on)" in some contexts but not others. In this case, I think you'll have to be more explicit: "every turn when the handheld is switched on and the message of the handheld is 0". It'd make a good feature request, though.
(0001112)
jmcgrew (administrator)
2011-03-27 14:13

Actually, you can make this work if you use relation syntax for the property, since relations are a context where "switched on handheld" is understood:

<code>
The verb to signal (it signals, they signal, it is signaling) implies the message property.

Every turn when the switched on handheld signals 0: say "The radio plays smooth jazz."
</code>
(0001113)
Fuchsia tude (reporter)
2011-03-27 15:17
edited on: 2011-03-27 15:18

Well, even if the relevant line of code is incorrect, the compiler shouldn't link to an irrelevant one.

(0001114)
jmcgrew (administrator)
2011-03-27 15:20

Indeed. That's clearly a bug, and the "not specific enough" language could stand to be improved too.
(0001367)
graham (administrator)
2011-10-15 03:48

The problem was indeed correctly issued, but at the wrong line. (It was being detected only when comparing the two different every turn rules to see which should take precedence: something Inform only needed to do when reading in the second one, which is why the problem was wrongly reported at the second rule's location and not the first.) Fixed.

- Issue History
Date Modified Username Field Change
2011-03-26 09:27 Fuchsia tude New Issue
2011-03-27 14:11 jmcgrew Effect (serious) Compiler rejects valid code => (cosmetic) Error message is badly worded
2011-03-27 14:11 jmcgrew Note Added: 0001111
2011-03-27 14:11 jmcgrew Severity serious => cosmetic
2011-03-27 14:11 jmcgrew Status new => acknowledged
2011-03-27 14:13 jmcgrew Note Added: 0001112
2011-03-27 15:17 Fuchsia tude Note Added: 0001113
2011-03-27 15:18 Fuchsia tude Note Edited: 0001113 View Revisions
2011-03-27 15:20 jmcgrew Note Added: 0001114
2011-03-28 10:16 EmacsUser Status acknowledged => confirmed
2011-10-15 03:48 graham Note Added: 0001367
2011-10-15 03:48 graham Status confirmed => resolved
2011-10-15 03:48 graham Resolution open => fixed
2011-10-15 03:48 graham Assigned To => graham
2014-05-07 07:34 jmcgrew Fixed in Version => 6L02
2014-05-07 07:34 jmcgrew Status resolved => closed


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker