Rules refuse to order correctly

I’ve posted about rule order before, but I think this is a little different. Unless there’s something missing, I7 is ordering these rules in an unambiguously wrong way:

[code]
Alley is a room. Street is south of Alley.

Report going (this is the report traveling impediments rule):
say “You trudge forward with difficulty…”;

The report traveling impediments rule is listed before the report being followed rule in the report going rulebook.

Report going to a room (this is the report being followed rule):
say “Out of the corner of your eye, you catch a flicker of movement.”;

The report being followed rule is listed before the describe room gone into rule in the report going rulebook.[/code]

From these declarations, it seems to me the only correct ordering is:

Report traveling impediments
Report being followed
Describe room gone into

But when this compiles, the actual order is:

Report being followed
Report traveling impediments
Describe room gone into

If I remove the “to a room” from the preamble of the Report being followed rule, the order is different, but still wrong:

report being followed
describe room gone into
report traveling impediments rule

I think I just figured out why. Rule ordering directives are processed in source order - no attempt is made to ensure that they all hold at the end of the ordering process. If I reverse the declarations, it works correctly. Is this a bug? If it’s not, it should be more clearly documented:

…this says what happens in the case of a direct conflict, but it’s ambiguous about what happens when a non-conflicting order is possible. I’m sure attempting to honor the ordering in a case like this would slow the compiler down, but I’d appreciate it. Rule order is very important!

That sounds like a bug to me. I was under the same impression that listing order (not source order) determined which rules would fire, and the documentation, as it stands is WRONG. I’d go ahead and file a bug report here.

Is that this bug?

I agree that this should be made to work better.

As far as I know, I7 just punts on the problem of ordering rule ordering declarations. (I trust that nobody wants to add rule ordering ordering declarations to the system.) So yeah, source order probably holds. (And the bug that mattw linked to is the same sort of thing.)

It does. The problem is one level higher.

What I find unclear is what’s going on under the hood here. The I7 compiler is going through the source in order, and attempting to apply each declaration to the rules as they stand, correct? That’s why the following bit from the Standard Rules works as desired:

But what happens when it hits one of these “listed before” declarations? In the original case, is it something like this?

Order before any declarations are processed:
report being followed
report traveling impediments
describe room gone into

Order after processing “The report traveling impediments rule is listed before the report being followed rule”
report traveling impediments
report being followed
describe room gone into

Order after processing “The report being followed rule is listed before the describe room gone into rule”
– well, it seems to me that the desirable behavior would be to check that this constraint is in fact respected, and do nothing. But does the compiler now try to put the report traveling impediments rule into the rulebook where it would anyway, while respecting the constraint – meaning that it gets put after the report being followed rule, because it’s less specific than the report being followed rule? If we omitted the second rule order declaration completely, would it work as intended? [UPDATE: Confirmed: if we omit the second declaration, we get the desired order.] Or have I got things completely wrong?

It seems opaque to me.

No, the “describe room gone into” rule appears first in the source because it’s in the Standard Rules. The “report being followed” rule is more specific, but the “report traveling impediments” rule is not, so it goes last. This is the actual order before any directives are processed:

The first directive, “report traveling impediments rule is listed before the report being followed rule,” actually puts the rules in the desired order:

But the second directive messes everything up. It appears that the compiler doesn’t check whether the “listed before” condition is already true, it just moves the report being followed rule to the beginning of the rulebook. It’s hard to imagine why it does this - it seems like the safest action (other than leaving it alone) would be to move the first rule immediately before the second rule, but it doesn’t do that. My guess is that it moves it to immediately after all the “listed first” rules if the rule it’s supposed to precede is not itself “listed first.” But maybe “listed before” is processed exactly the same as “listed first,” rendering it a meaningless distinction.

OK, I’m very puzzled here. I thought the problem had to do with the specificity of the rules, but it seems to me that the RBF rule is less specific than the RTI rule, so it should be getting listed after it even when the second rule order declaration reshuffles the rulebook – if that’s what’s happening. [Which is what section 18.4 of the documentation somewhat suggests: “the… rule would now be placed in specificity order only in the first half of the… rulebook,” viz., the half before the rule it’s explicitly listed before.]

But I can report that if you change the RBF rule heading to “report going to a room,” then the rules wind up in the correct order. So it seems as though it has something to do with specificity – either that, or the behavior isn’t very predictable.

Unfortunately, those helpful little things in the index that explain why the rules are in certain order aren’t showing up here. They show up in rulebooks that are listed under the “rules” tab, but apparently not in rulebooks listed under the “Actions” tab. [As seen in section 18.5.]

I think specificity affects the initial ordering, which in turn affects what happens when ordering directives are applied.