|Anonymous | Login | Signup for a new account||2018-10-19 20:49 PDT|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000554||Core Inform||Phrases and functional programming||public||2011-02-12 09:32||2014-05-07 07:33|
|Target Version||Fixed in Version||6L02|
|Summary||0000554: With multiple definitions of an adjective applying to the same kind, only the first is honored.|
|Description||Multiple definitions for the same adjective result in at least one of the definition statements being ignored. No problem message is produced, and the documentation in WWI 6.4 strongly implies that the multiple statements should work correctly. Combining the conditions from the multiple definitions into one definition statement works as intended.|
If ignoring one statement is intended behavior, I suggest a problem message be created to indicate the second statement is invalid and/or that WWI 6.4 be updated to clarify why it is not allowed.
The attached source results in the following I6 code:
- - - -
[ Adj_31_t1_v9 ! meaning of "a doggie-snack"
t_0 ! Call parameter 'it' = thing
if (t_0 ofclass K2_thing) return (((((Adj_44_t1_v9(t_0))))));
if (t_0 ofclass K2_thing) return ((((t_0 == I92_newspaper)))); ! *
- - - -
In particular, the condition on the marked line can never have any effect, but then the first definition is used rather than the last, which is inconsistent with the way that ``To...'' phrases are handled.
|Minimal Source Text To Reproduce|
"Bug Demonstration" by Otis Kitchen is a room. A person called the dog is here. A beef stick and a wedge of cheese are edible things in the Kitchen. A newspaper is here. [DOES NOT WORK AS INTENDED] Definition: A thing is a doggie-snack if it is edible. Definition: A thing is a doggie-snack if it is the newspaper. [WORKS AS INTENDED] [ Definition: A thing is a doggie-snack if it is edible or it is the newspaper. ] After examining something, say "[The noun] does[if the noun is not a doggie-snack] not[end if] look like something the dog would eat." instead. Before the dog eating the newspaper: now the newspaper is edible. Every turn: if the dog can see a doggie-snack: let prize be an object; let prize be a random visible doggie-snack; silently try the dog taking the prize; if the dog is carrying the prize, try the dog eating the prize. test me with "z / z / z"
|Additional Information||Commenting the [DOES NOT WORK AS INTENDED] block and uncommenting the [WORKS AS INTENDED] block will produce the intended behavior.|
|Tags||No tags attached.|
|Effect||(mild) Compiler accepts invalid code|
Ron Newcomb (reporter)
In general, Inform allows defining something multiple times, the last definition is the one that is used. It's a feature to allow overriding of definitions created in extensions and the standard rules. You can do this with To-phrases as well.
At least I think that's what's going on here.
That said, it probably *is* an error for multiple definitions within the same *file*.
I believe that this is intended behavior; see WI 21.9, in particular points 2 and 3, which describe the feature that Ron mentioned. The occupancy example in WI 6.4 doesn't fall under these points' purview because the two definitions apply to separate kinds---supporters and rooms---whereas here both definitions deal with things.
I will ask Jesse to move this report to the documentation project; perhaps more warning could be given in WI 6.4, and maybe WI 21.9 could mention that ``Definition:'' is subject to the same rules as ``To ....''
Ron Newcomb (reporter)
edited on: 2011-02-14 19:01
Documentation is always nice, but I can't think of a single reason why re-defining the same adjective over the same domain within the same file is anything but an error that needs brought to the author's attention. Different files, OK, he's overriding an extension's, but not the same file.
I guess I'm calling for a new Problem message for that specific instance, which is pretty close to what Otis wanted save I'm adding the "same file" restriction.
Actually, what brought me to reporting this as an issue is that it is the SECOND statement being ignored in my example, not the first. Otherwise, I would have just assumed the definition was being redefined with the second statement -- not unreasonable.
Regarding Ron's "same adjective, same domain, same file" point, I can see that. I guess the potential clarification in WWI that would have helped would be explicitly pointing out that in the code example shown with two different definitions using the same adjective, this only works because the domains are different.
Sorry for the misunderstanding; confirmed. Contrary to my claim in 0000554:0001023, WI 21.9 does not apply; I've updated the description to show what is going on.
Ron, you might want to request that problem message on UserVoice.
|On the whole I agree that it's helpful to throw a problem message if the same file of source text defines the same adjective twice over the same domain, so I've done that. If two such definitions occur in different files, the source text is the one that prevails, so that you can override extension definitions.|
|2011-02-12 09:32||otistdog||New Issue|
|2011-02-12 18:46||jmcgrew||Status||new => acknowledged|
|2011-02-13 04:12||Ron Newcomb||Note Added: 0001016|
|2011-02-13 21:48||EmacsUser||Note Added: 0001023|
|2011-02-14 18:52||Ron Newcomb||Note Added: 0001030|
|2011-02-14 19:01||Ron Newcomb||Note Edited: 0001030||View Revisions|
|2011-02-14 20:02||otistdog||Note Added: 0001031|
|2011-02-14 20:34||EmacsUser||Note Added: 0001032|
|2011-02-14 20:34||EmacsUser||Status||acknowledged => confirmed|
|2011-02-14 20:34||EmacsUser||Description Updated||View Revisions|
|2011-02-14 20:40||EmacsUser||Summary||With multiple definitions, some may be ignored. => With multiple definitions of an adjective applying to the same kind, only the first is honored.|
|2013-07-02 14:26||Shadow Wolf||Issue Monitored: Shadow Wolf|
|2014-02-08 14:31||graham||Note Added: 0002453|
|2014-02-08 14:31||graham||Status||confirmed => resolved|
|2014-02-08 14:31||graham||Resolution||open => fixed|
|2014-02-08 14:31||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|