Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001180Documentation, Examples, and Web SiteWriting with Informpublic2014-01-12 18:332014-05-07 07:38
Reportermattweiner 
Assigned Tograham 
PrioritynormalSeveritymildReproducibilityalways
StatusclosedResolutionfixed 
Platformx86OSMac OS XOS Version10.7
Product Version6G60 
Target VersionFixed in Version6L02 
Summary0001180: WI 18.4 is unclear as to how "listed before" declarations handle rules that are tied with respect to specificity
DescriptionSection 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 InformationAs 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)."
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0002288)
EmacsUser (manager)
2014-01-13 09:13

Added links and confirmed.
(0002358)
graham (administrator)
2014-01-25 09:35

This is rather more clearly explained now.

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