Anonymous | Login | Signup for a new account | 2018-04-20 03:38 PDT | ![]() |
Main | My View | View Issues | Change Log | Roadmap |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | |||||
ID | Project | Category | View Status | Date Submitted | Last Update | |
0000276 | Core Inform | Assertions and creations | public | 2010-09-03 00:47 | 2010-10-28 00:30 | |
Reporter | adjusting | |||||
Assigned To | emshort | |||||
Priority | normal | Severity | mild | Reproducibility | always | |
Status | closed | Resolution | fixed | |||
Platform | x86 | OS | Mac OS X | OS Version | 10.6 | |
Product Version | 6E72 | |||||
Target Version | Fixed in Version | 6F95 | ||||
Summary | 0000276: Can't use a variable named target | |||||
Description | I had a project from an old version of Inform 7. I tried to compile it with 6E72 and it failed to compile. It turns out this is because I had a variable named target. Not really a big deal since I can just rename my variable and it works fine. The documentation however uses the variable target throughout without any mention that it should be avoided, and the following appears in release notes: 26.9 It is now allowed to create a temporary value (i.e., a local variable) with "let" whose name coincides with that of a thing, room or property. Previously this triggered problem messages, and was a particular problem for extensions and the Standard Rules, which had to avoid "let" names that might hit any of the things created by the user. (For instance, several people reported it as a bug that creating a property called "target" caused problems - this was because the Standard Rules use a "let" variable called "target" in places.) | |||||
Minimal Source Text To Reproduce | The void is a room. The target is a variable. | |||||
Additional Information | Launching: ni "-rules" "/Data/IF/Inform.app/Contents/Resources/Inform7/Extensions" "-package" "/private/tmp/foo.inform" "-extension=z8" Inform 7 build 6E72 has started. ++ 0% (Lexical analysis) ++ 5% (Semantic analysis) ++ 15% (Drawing inferences) ++ 20% (Binding rulebooks) ++ 23% (Binding rulebooks) ++ 26% (Binding rulebooks) ++ 29% (Binding rulebooks) I've now read your source text, which is 11 words long. I've also read Standard Rules by Graham Nelson, which is 39419 words long. ++ 32% (Binding rulebooks) ++ 35% (Binding rulebooks) ++ 38% (Binding rulebooks) ++ 41% (Generating code) ++ 44% (Generating code) ++ 47% (Generating code) ++ 50% (Generating code) ++ 53% (Generating code) ++ 56% (Generating code) ++ 59% (Generating code) ++ 62% (Generating code) ++ 65% (Generating code) ++ 68% (Generating code) ++ 71% (Generating code) ++ 74% (Generating code) ++ 77% (Generating code) ++ 80% (Generating code) ++ 83% (Generating code) ++ 86% (Generating code) ++ 89% (Generating code) ++ 92% (Generating code) ++ 95% (Generating code) In Part SR4 - Actions, Section SR4/3 - Standard actions which move the actor in the extension Standard Rules by Graham Nelson: >--> You wrote 'let the target be nothing' (the Standard Rules, line 1945), but 'target' seems to be a non-temporary variable, whereas I was expecting to find a temporary named value there. I was trying to match one of these phrases: 1. let (target - a new name) be (nothing - description of relations of values to values) 2. let (target - a new name) be (nothing - name of kind) 3. let (target - a new name) be (nothing - value) 4. let (target - a temporary named value) be (nothing - value) This was what I found out: target = a non-temporary variable, holding a number nothing = an object >--> You wrote 'let the target be nothing' (the Standard Rules, line 1979), but 'target' seems to be a non-temporary variable, whereas I was expecting to find a temporary named value there. I was trying to match one of these phrases: 1. let (target - a new name) be (nothing - description of relations of values to values) 2. let (target - a new name) be (nothing - name of kind) 3. let (target - a new name) be (nothing - value) 4. let (target - a temporary named value) be (nothing - value) This was what I found out: nothing = an object >--> You wrote 'let the target be the holder of the actor' (the Standard Rules, line 2132), but 'target' seems to be a non-temporary variable, whereas I was expecting to find a temporary named value there. I was trying to match one of these phrases: 1. let (target - a new name) be (holder of the actor - description of relations of values to values) 2. let (target - a new name) be (holder of the actor - name of kind) 3. let (target - a new name) be (holder of the actor - value) 4. let (target - a temporary named value) be (holder of the actor - value) This was what I found out: holder of the actor = an instruction to work out an object, which results in an object Inform 7 has finished. Compiler finished with code 1 | |||||
Tags | No tags attached. | |||||
Effect | (serious) Compiler rejects valid code | |||||
Attached Files | ||||||
![]() |
|
(0000491) emshort (administrator) 2010-09-03 02:14 edited on: 2010-09-03 02:15 |
This is a limitation of the system, and is not the same problem whose eradication was mentioned by the change log (which would deal with you having a room, thing, or property called target, as in "Target is a room", "The target is a thing.", etc.). The problem message does clearly identify what the problem is ("non-temporary variable"). |
(0000493) adjusting (reporter) 2010-09-03 10:45 |
But isn't it still a problem that the documentation contains examples which would fail in the same way, such as the following in section 4.12: The target is a number variable. The target is 23. Also, the compiler says the problem is in the Standard Rules and doesn't give the user any indication that the problem could be in their Source Text. |
(0000494) emshort (administrator) 2010-09-03 11:24 |
Okay, there are two issues here. The documentation issue is easily fixed, and I've sent in a patch for that. The bigger issue is a very fair point: it would be nice if it were impossible for the user's behavior to cause spurious failures in the standard rules, or, failing that, if the problem message generator could figure out to identify conflicts based on the conflicting item in the user's own code rather than in the SR. However, I think this is really equivalent to a feature request for better handling of namespace issues ( https://inform7.uservoice.com/forums/57320-general/suggestions/751508-namespace-addition-of-namespace-control?ref=title [^] might be applicable), not a point where Inform is failing to behave to spec. |
(0000496) graham (administrator) 2010-09-03 12:06 |
I have, however, fixed the larger point in this case; name-clashes should now occur less between local and global variables. |
![]() |
|||
Date Modified | Username | Field | Change |
2010-09-03 00:47 | adjusting | New Issue | |
2010-09-03 02:14 | emshort | Note Added: 0000491 | |
2010-09-03 02:15 | emshort | Note Edited: 0000491 | View Revisions |
2010-09-03 02:16 | emshort | Status | new => closed |
2010-09-03 02:16 | emshort | Assigned To | => emshort |
2010-09-03 02:16 | emshort | Resolution | open => no change required |
2010-09-03 10:45 | adjusting | Note Added: 0000493 | |
2010-09-03 10:45 | adjusting | Status | closed => feedback |
2010-09-03 10:45 | adjusting | Resolution | no change required => reopened |
2010-09-03 11:24 | emshort | Note Added: 0000494 | |
2010-09-03 11:30 | emshort | Status | feedback => resolved |
2010-09-03 11:30 | emshort | Resolution | reopened => fixed |
2010-09-03 11:30 | emshort | Additional Information Updated | View Revisions |
2010-09-03 12:06 | graham | Note Added: 0000496 | |
2010-10-25 21:14 | jmcgrew | Fixed in Version | => 6F95 |
2010-10-28 00:30 | jmcgrew | Status | resolved => closed |
Copyright © 2000 - 2010 MantisBT Group |