Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000082Core InformPropertiespublic2010-06-21 11:272010-07-01 23:07
Assigned Tograham 
Platformx86OSMac OS XOS Version10.4
Product Version6E59 
Target VersionFixed in Version6E72 
Summary0000082: Well-defined adjectives depending on a truth state property fail if the adjective is one word
DescriptionThe source attached results in::

Problem. You gave as a definition 'an animal is across-Wallace's-line if its Australian origin is false' : but the property value given here has a kind which can't be subject to numerical comparisons, so it doesn't make sense to talk about it being 'more' or 'less'.

if across-Wallace's-line is hyphenated, so that it forms one word. Removing a hyphen seems to result in the expected behavior.
Minimal Source Text To Reproduce
Somewhere near the East Asian Continental Shelf is a room.
An animal has a truth state called Australian origin.
Definition: an animal is across-Wallace's-line if its Australian origin is false.
TagsNo tags attached.
Effect(serious) Compiler rejects valid code
Attached Files

- Relationships

-  Notes
jmcgrew (administrator)
2010-06-21 12:30

I believe this is an "error message is badly worded" issue: the "if its ... is ..." form of adjective is described in 6.6 for numeric comparisons, and truth state is not a numeric type. However, the problem message refers to "more" and "less" which make no sense in this context.

On the other hand, it would make sense to allow the adjective form specifying an exact value for other types, and in fact the definition is allowed if the adjective name is more than one word. But when defined that way, the adjective can't be used in an assertion about an object (we can test it but not set it).
EmacsUser (manager)
2010-06-21 12:41

Ah, you are right. Thanks for pointing that out.
graham (administrator)
2010-06-22 14:56

I agree with Jesse's second thought, i.e., I think the source here was valid if unusual. The problem message was a last-minute addition to 6E59, and I made it a little too trigger-happy. (Actually I remember wondering about this case at the time, but somehow there was a lot to do, and I moved on without thinking about it further. Or enough, as it turned out.)

- Issue History
Date Modified Username Field Change
2010-06-21 11:27 EmacsUser New Issue
2010-06-21 11:28 EmacsUser Severity mild => serious
2010-06-21 12:30 jmcgrew Effect (serious) Compiler rejects valid code => (cosmetic) Error message is badly worded
2010-06-21 12:30 jmcgrew Note Added: 0000104
2010-06-21 12:30 jmcgrew Severity serious => cosmetic
2010-06-21 12:30 jmcgrew Status new => confirmed
2010-06-21 12:41 EmacsUser Note Added: 0000105
2010-06-22 14:56 graham Note Added: 0000128
2010-06-22 14:56 graham Status confirmed => resolved
2010-06-22 14:56 graham Resolution open => fixed
2010-06-22 14:56 graham Assigned To => graham
2010-06-22 15:23 jmcgrew Effect (cosmetic) Error message is badly worded => (serious) Compiler rejects valid code
2010-06-22 15:23 jmcgrew Severity cosmetic => serious
2010-06-30 18:07 jmcgrew Fixed in Version => 6E72
2010-07-01 23:07 jmcgrew Status resolved => closed

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker