Semicolon bug in the standard rules? [Never mind - resolved]

(Edit: This problem has been resolved. It was just me not having a clue.)

These are the first two rules for the Exiting action:

Check an actor exiting (this is the convert exit into go out rule):
	let the local room be the location of the actor;
	if the container exited from is the local room:
		if the room-or-door outside from the local room is not nothing,
			convert to the going action on the outside;

Check an actor exiting (this is the can’t exit when not inside anything rule):
	let the local room be the location of the actor;
	if the container exited from is the local room, stop the action with
		library message exiting action number 1 for the actor.

Do you see the semicolon?
At first I thought that this was some sort of superior technique by Graham, but what is also strange about these rules, is that you can’t put any new rule between them. Such rules end up at the bottom of the rulebook instead. This is why extensions modifying exiting, has to change the first rule directly, to prevent the second rule from taking effect (claiming “But you aren’t in anything at the moment.”).

(If this really is a bug, could you report it, please? I have a very old bug-reporting user somewhere, but I don’t know its name or password.)

The rules are separated by a blank line in my copy of the Standard Rules.

Yes, but as you can see, the semicolon is still there.
(I copied the rules from the Appendix A documentation instead, because I thought opening Standard Rules directly might make I7 explode or something.)

A blank line is taken to be the end of a rule body, even after a semicolon.

Really? … You seem to be right.
So how come these rules “stick together”?
If I say that my new rule is listed after the first rule, the rules will still ignore it.

This does what I think you’re trying to do:

The Kitchen is a room. "Room."

The new exit rule is listed before the can't exit when not inside anything rule in the check exiting rulebook.

Check an actor exiting (this is the new exit rule):
	say "Hello."

You didn’t provide an example of your code, but it sounds like you wrote something like

The new exit rule is listed after the convert exit into go out rule in the check exiting rulebook.

This has no effect because, without an ordering qualification, a new “check exiting” rule goes at the end of the rulebook. So this declaration is already true.

:astonished:

I had no idea. …and I’ve adhered to “after” in all my rule changes. I think you just prevented a lot of problems for me. I have to go over all my extensions now.

This of course means that listing a rule before another rule, would technically just place it anywhere before that rule. I really wish there was a better way of ordering rules.

As you can see from my example, the compiler makes the minimum necessary movement to satisfy your ordering declarations.

Now I’m wondering what happens if I order two rules to each be placed before the other. Which one wins?

(Manual chapter 18.4.)

Rule ordering can be pretty confusing – hey, no one really explained what was going on there to me, at least not in way I wound up understanding.

I blame the manual not explicitly stating that listing a rule after another rule, will not list it immediately after. It seems people dread to “mess with the rules”, but for me that’s where most solutions lie, so that chapter needs to be easy to understand.

Ooh, this is probably why my change to Threaded Conversation isn’t quite working. Changing now.