Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000554Core InformPhrases and functional programmingpublic2011-02-12 09:322014-05-07 07:33
Assigned Tograham 
Platformx86OSWindowsOS VersionXP
Product Version6G60 
Target VersionFixed in Version6L02 
Summary0000554: With multiple definitions of an adjective applying to the same kind, only the first is honored.
DescriptionMultiple 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.


Definition: A thing is a doggie-snack if it is edible.

Definition: A thing is a doggie-snack if it is the newspaper.

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 InformationCommenting the [DOES NOT WORK AS INTENDED] block and uncommenting the [WORKS AS INTENDED] block will produce the intended behavior.
TagsNo tags attached.
Effect(mild) Compiler accepts invalid code
Attached Files

- Relationships

-  Notes
Ron Newcomb (reporter)
2011-02-13 04:12

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*.
EmacsUser (manager)
2011-02-13 21:48

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)
2011-02-14 18:52
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.

otistdog (reporter)
2011-02-14 20:02

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.
EmacsUser (manager)
2011-02-14 20:34

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.
graham (administrator)
2014-02-08 14:31

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.

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker