|Anonymous | Login | Signup for a new account||2018-04-22 18:25 PDT|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001180||Documentation, Examples, and Web Site||Writing with Inform||public||2014-01-12 18:33||2014-05-07 07:38|
|Platform||x86||OS||Mac OS X||OS Version||10.7|
|Target Version||Fixed in Version||6L02|
|Summary||0001180: WI 18.4 is unclear as to how "listed before" declarations handle rules that are tied with respect to specificity|
|Description||Section 18.4 states:|
"We can also specify that the rule needs to appear before, or after, some other named rule in the same rulebook:
The collapsing bridge rule is listed before the moving doorways rule in the instead rules.
Instead of being placed in specificity order in the whole "instead" rulebook, the "collapsing bridge" rule would now be placed in specificity order only in the first half of the "instead" rulebook - the rules from the start up to (but not including) the "moving doorways" rule."
The test case for 0000514 is a case in which rules 1 and 3 are equally specific and more specific than rule 2. In Graham's explanation of why that case works the way it does (0000514:0002285), he explains that when the declaration "The 1st rule is listed before the 2nd rule in the for enacting rulebook" is processed, "1 is placed before 2, giving 3, 1, 2, Final." But it is not clear from the documentation why 1 ought to be moved after 3, since 1 and 3 are equally specific, and leaving 1 in place would respect both specificity and the "listed before" declaration.
It appears as though "listed before" declarations may move the listed rule to the last place in the rulebook that is compatible with both specificity and the "listed before" declaration, but this is not made clear in section 18.4.
|Minimal Source Text To Reproduce|
Our failing action is a number that varies. To decide if our planning actor cannot try (N - number): no. Enacting [for someone] something is an activity on people. For enacting when our failing action is less than one (this is the 1st rule): do nothing instead. For enacting for someone off-stage (this is the 2nd rule): do nothing instead. For enacting when our planning actor cannot try our failing action (this is the 3rd rule): do nothing instead. Last for enacting for someone (called our enactor) (this is the Final rule):do nothing. The 1st rule is listed before the 2nd rule in the for enacting rulebook. There is room.
|Additional Information||As Graham says in 0000514:0002285, the effect of the listed before declaration is to reorder the rulebook from 1, 3, 2, F to 3, 1, 2, F. When hovering over the link that joins rule 3 to rule 1 in the Rules tab of the index, the tooltip states, "These rules are equally ranked, so their order is determined by which was defined first (or by explicit 'listed in' sentences)."|
|Tags||No tags attached.|
Added links and confirmed.
|This is rather more clearly explained now.|
|2014-01-12 18:33||mattweiner||New Issue|
|2014-01-13 09:13||EmacsUser||Note Added: 0002288|
|2014-01-13 09:13||EmacsUser||Status||new => confirmed|
|2014-01-13 09:13||EmacsUser||Description Updated||View Revisions|
|2014-01-13 09:13||EmacsUser||Additional Information Updated||View Revisions|
|2014-01-25 09:35||graham||Note Added: 0002358|
|2014-01-25 09:35||graham||Status||confirmed => resolved|
|2014-01-25 09:35||graham||Resolution||open => fixed|
|2014-01-25 09:35||graham||Assigned To||=> graham|
|2014-05-07 07:37||jmcgrew||Fixed in Version||=> 6L02|
|2014-05-07 07:38||jmcgrew||Status||resolved => closed|
|Copyright © 2000 - 2010 MantisBT Group|