Mantis Bug Tracker
Main | My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000276Core InformAssertions and creationspublic2010-09-03 00:472010-10-28 00:30
Reporteradjusting 
Assigned Toemshort 
PrioritynormalSeveritymildReproducibilityalways
StatusclosedResolutionfixed 
Platformx86OSMac OS XOS Version10.6
Product Version6E72 
Target VersionFixed in Version6F95 
Summary0000276: Can't use a variable named target
DescriptionI 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 InformationLaunching: 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
TagsNo tags attached.
Effect(serious) Compiler rejects valid code
Attached Files

- Relationships

-  Notes
(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.

- Issue History
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
Powered by Mantis Bugtracker