Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000209Core InformAssertions and creationspublic2010-07-18 14:572010-10-28 00:30
Assigned Tograham 
Platformx86OSWindowsOS VersionXP
Product Version6E72 
Target VersionFixed in Version6F95 
Summary0000209: Failing to make all parts of a kind kinds themselves, generates unclear compile errors.
DescriptionIn the attached source text the author has forgotten to declare hairspray as a kind, so Inform is assuming it to be an object. That turns out to be an okay assumption in the sense that there's only one hairstyle in the model world, but it means that ``A hairspray is part of every hairstyle'' is syntactically invalid:

Problem. You wrote 'A hairspray is part of every hairstyle' : but 'every' can only be used on the other side of the verb, because of limitations in Inform (but also to avoid certain possible ambiguities). In general, 'every' should be applied to the subject of an assertion sentence and not the object. Thus 'Sir Francis prefers every blonde' is not allowed, but 'Every blonde is preferred by Sir Francis' is.

The original reporter pointed out two issues with this error. First, it seems to imply that ``every'' cannot be used this way at all, when in fact the syntax is acceptable when hairspray is declared as a kind. Second, there is no indication that ``hairspray'' is being interpreted as a thing.
Minimal Source Text To Reproduce
A hairstyle is a kind of thing.
A hairspray is part of every hairstyle.
The lobby is a room.
The pretender is in the lobby.
The pretender carries a hairstyle called the pretentious look.
Additional InformationThis is one of the two error messages in the original report; the other is dealt with in 0000218.
TagsNo tags attached.
Effect(cosmetic) Error message is badly worded
Attached Files

- Relationships
related to 0000218closedgraham Contradiction message fails to account for the underlying cause 

-  Notes
EmacsUser (manager)
2010-07-24 15:38

Andreas: I've tried to split this into two separate bugs. If I've somewhere confounded the intent of your bug report in the process, add a note and let me know.
Andreas (reporter)
2010-07-25 06:18

I didn't make much sense of it, but as long as the rewritten form is clear to you (who I assume actually know how things are supposed to work in the first place), you can phrase things however you want, but you missed a couple of things:

1. That piece of code should work, because you wrote "a hairspray", and not "hairspray". As long as you write "a" or "an" in front of the part, Inform will figure out that the hairspray is a kind and not a thing.

2. Either the compiler is right and the manual is wrong, or the manual is right and the compiler is wrong. Make sure to update the manual if you decide that the compiler is right about the phrase not being allowed.

3. Using the working circumstance of both of these phrases, you can declare exactly the same relation twice over, without the compiler complaining about already having declared it.

Hopefully that was all the issues I had with this bug.
EmacsUser (manager)
2010-07-26 08:41

1. Hmm, from my reading of WI 4.14 and WI 4.15 the determining factor seems to be whether ``hairspray'' was declared as a kind, not what article is used. The compiler in any case follows this logic:

A nose is a kind of thing.
[A] Nose is part of every person.
There is a person.
There is a room.

will look the same on the world page of the index whether or not the article ``a'' is included. That said, I certainly don't have a comprehensive knowledge of Inform's documentation, so I could be missing something.

2. My understanding here is that the documentation is right and that the compiler's error message needs to change. It's almost right, but needs to say something more along the lines of:

I'm interpreting 'a hairspray' as one particular thing, rather than as an instance of a kind called 'hairspray', in which case 'every' can only be used on the other side of the verb...

3. Duly noted. However, this is expected behavior. For instance, the following code also compiles just fine.

There is a room.
The player has a number called height.
The height of the player is 416.
The height of the player is 416.

If you'd like warnings on duplicate declarations, put in a request at [^]
graham (administrator)
2010-09-01 12:34

I've improved this problem message. (See also the related report, also now resolved.)

- Issue History
Date Modified Username Field Change
2010-07-18 14:57 Andreas New Issue
2010-07-18 15:28 Andreas Note Added: 0000305
2010-07-18 16:59 jmcgrew Note Added: 0000311
2010-07-18 16:59 jmcgrew Priority low => normal
2010-07-18 16:59 jmcgrew Status new => feedback
2010-07-18 16:59 jmcgrew Category Actions => Assertions and creations
2010-07-18 16:59 jmcgrew Description Updated View Revisions
2010-07-18 16:59 jmcgrew Steps to Reproduce Updated View Revisions
2010-07-18 18:51 Andreas Note Added: 0000313
2010-07-18 18:51 Andreas Status feedback => new
2010-07-18 22:39 jmcgrew Steps to Reproduce Updated View Revisions
2010-07-18 22:39 jmcgrew Note Deleted: 0000311
2010-07-18 22:39 jmcgrew Note Deleted: 0000313
2010-07-18 22:40 jmcgrew Note Deleted: 0000305
2010-07-18 22:40 jmcgrew Status new => acknowledged
2010-07-24 15:23 EmacsUser Issue cloned 0000218
2010-07-24 15:38 EmacsUser Note Added: 0000344
2010-07-24 15:38 EmacsUser Status acknowledged => confirmed
2010-07-24 15:38 EmacsUser Description Updated View Revisions
2010-07-24 15:38 EmacsUser Steps to Reproduce Updated View Revisions
2010-07-24 15:38 EmacsUser Additional Information Updated View Revisions
2010-07-25 06:18 Andreas Note Added: 0000349
2010-07-26 08:41 EmacsUser Note Added: 0000351
2010-09-01 12:34 graham Note Added: 0000483
2010-09-01 12:34 graham Status confirmed => resolved
2010-09-01 12:34 graham Resolution open => fixed
2010-09-01 12:34 graham Assigned To => graham
2010-09-01 23:41 jmcgrew Relationship added related to 0000218
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