|Anonymous | Login | Signup for a new account||2018-01-21 14:26 PST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001220||Core Inform||Assertions and creations||public||2014-04-13 11:24||2014-05-07 07:33|
|Target Version||Fixed in Version||6L02|
|Summary||0001220: Misleading problem messages when if phrases are used outside of rules.|
|Description||The problem messages produced when using one-line or 'colon and indentation' if phrases outside of rules do not indicate that using the if phrases outside of rules is a problem. The problem messages identify other causes for the errors instead.|
For a one-line if example, the problem message says "this seems to give something a name which contains double-quoted text, which is not allowed."
For colon and indentation if, the problem message says "the tabs here seem to be misaligned, and I can't determine the structure."
|Minimal Source Text To Reproduce|
R is a room. Bob is a man in R. [colon and indentation if example - comment out this block to see the problem message for the one-line if example] If the player is in R: say "You're hanging out with Bob!"; otherwise: say "You miss Bob....". [one-line if example] If Bob is a man, say "Bob's the man!".
|Additional Information||Relevant manual section is Section 2.17(b), which clearly states that if phrases can only be used inside rules.|
Nominally, this is a duplicate of 0000474, but the reporter makes the following additional suggestions for improving matters (see 0001220:0002618 below):
- In WI 2.2, add an explicit statement that assertions must always occur outside of rules, phrases, and definitions, whereas phrase invocations (including control structures) must always appear in one of the three. This may have already been done.
- Use lone commas and terminating colons are further triggers for the clarifying footnote.
|Tags||No tags attached.|
|Effect||(cosmetic) Error message is badly worded|
edited on: 2014-04-14 13:46
After reading issue 000474, I wanted to better explain why I think clarifying the error messages and/or documentation related to if phrases outside of rules would make a significant positive impact. I sincerely appreciate the developers' work on Inform, and I do respect developer decisions about handling issues. I promise not to reopen this one again!
The footnote from 000474, crafted for "cases where control structures appear in assertion sentences known to be erroneous," is not showing up in any if phrase examples I have tried. If feasible, adding such a message would make it much easier to find the root cause of errors where if phrases are used outside of rules. For a simpler helpful change, Section 2.2 could mention that (some? all?) phrases can only be used inside rules. The text from Section 2.17(b) does make that point about if phrases, but 2.2 is where rules and phrases are introduced.
(A message similar to graham's footnote from 000474 very helpfully shows up when incorrectly using if... begin... end if outside of a rule: "I am reading the sentence 'If Bob is a man begin' as a declaration of the initial state of the world, so I'm expecting that it will be definite. The only way I can construe it that way is by thinking that 'If Bob' and 'man begin' are two different things, but that doesn't make sense, and the 'if' makes me think that perhaps you did not mean this as a definite statement after all. Although 'if...' is often used in rules and definitions of what to do in given circumstances, it shouldn't be used in a direct assertion." )
For one-line blocks, it seems like the "If [A], [B]." structure is a good indicator than an author probably meant to make an if phrase. That's why I was confused by 000474's valid sentence example, "If DVD is in the Library." Though this sentence starts with “if”, it doesn't match the structure of an if phrase. I haven't been able to construct any valid sentence that uses the one-line if phrase structure ("If [A], [B].") outside of a rule.
The invalid sentence example from issues 000474 was "If player is in Kitchen, say 'Hi.'". It resulted in an error about giving something a name which contains double-quoted text. This makes sense because the program interprets this as saying an object (If player) is in Kitchen and in a place called “say 'Hi'", and it doesn't like the place name "say 'Hi'". If you replace the second half of the sentence with something else, it's still interpreted as the object (If player) being in two places at once, which is understandably still a problem. The problem message is "You wrote 'If player is in Kitchen, and Bob is in R', but also 'If player is in Kitchen, and Bob is in R': that seems to be saying that the same object (If player) must be in two different places (Kitchen and Bob is in R). This looks like a contradiction."
These error messages are correctly identifying problems, but they're not getting at the root cause. Because the "If [A], [B]" structure gives a decent indication of author intent, sentences like that could be a great place to trigger problem message footnotes about using if phrases improperly, like the if...begin...end if message already has.
The “colon and indentation” if phrase structure also seems significantly different from valid sentences. The problem message for the colon and indentation example in my issue is: “The phrase or rule definition 'If the player is in R' is written using the 'colon and indentation' syntax for its 'if's, 'repeat's and 'while's, where blocks of phrases grouped together are indented one tab step inward from the 'if ...:' or similar phrase to which they belong. But the tabs here seem to be misaligned, and I can't determine the structure. The first phrase going awry in the definition seems to be 'say "You're hanging out with Bob!"', in case that helps.”
Again, the problem message identifies a real problem – not being able to determine the structure of a phrase – but the message misleads a user attempting to debug that example. If the structure (a colon and indentation block starting with if) is enough to make a good guess about author intent, this would be another nice place for a footnote.
edited on: 2014-04-14 16:51
First off, don't worry about reopening issues. If there's something more to add to the discussion, then you should certainly feel free to add it.
I think you make a number of fair points. Regarding one of them, the 0000474 fix is slated to go out the end of this month, so that's why you're not seeing it. For two others,
- - - -
There is a room.
If DVD, Now You See Me are things.
There is a thing called Three is a Magic Number.
The IF rulebook is an object based rulebook.
IF Three is a Magic Number:
say "Yes it is."
- - - -
is an example of a treacherous, though admittedly unlikely source.
As for the remaining points, I'll turn the decisions over to Graham.
|Inform makes a constructive response to the one-line version as a result of 0000474; it now makes a similar effort for the multi-line version, too.|
|2014-04-13 11:24||xxiggy||New Issue|
|2014-04-13 12:23||xxiggy||Note Added: 0002617|
|2014-04-13 12:23||xxiggy||Note Deleted: 0002617|
|2014-04-14 11:07||EmacsUser||Status||new => closed|
|2014-04-14 11:07||EmacsUser||Resolution||open => duplicate|
|2014-04-14 11:07||EmacsUser||Relationship added||duplicate of 0000474|
|2014-04-14 13:39||xxiggy||Note Added: 0002618|
|2014-04-14 13:39||xxiggy||Status||closed => feedback|
|2014-04-14 13:39||xxiggy||Resolution||duplicate => reopened|
|2014-04-14 13:46||xxiggy||Note Edited: 0002618||View Revisions|
|2014-04-14 16:46||EmacsUser||Note Added: 0002619|
|2014-04-14 16:46||EmacsUser||Status||feedback => confirmed|
|2014-04-14 16:46||EmacsUser||Additional Information Updated||View Revisions|
|2014-04-14 16:51||EmacsUser||Note Edited: 0002619||View Revisions|
|2014-05-03 15:32||graham||Note Added: 0002645|
|2014-05-03 15:32||graham||Status||confirmed => resolved|
|2014-05-03 15:32||graham||Resolution||reopened => fixed|
|2014-05-03 15:32||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|