Redirecting action in Check, Instead, and Before rules

I keep changing my mind about how to redirect action in a check rule. I’m trying to formulate some principles.

Occasionally I use the “convert” phrase like the Standard Rules does. I feel like I’m messing with something I don’t understand, but it looks like something that’s built to handle just this situation.

Other times I just want to change the noun or the second noun, so I do that without changing the action.

The rest of the time I use a “try” phrase.

I’ve had issues in testing with various methods, so I’d like to try to make the differences plain. I’m guessing at some of this, so let me know if I’ve missed anything or made any mistakes.

A “try” phrase invokes ALL the relevant rules for the new action. So if the source says “instead of taking the red ball” and your code says “try taking a random ball that is in the box,” that might be invoked some times.

Changing nouns continues the current rulebook, so if the action was originally taking the box, the Instead rule will never run. In fact a “check taking the red ball” would not apply if it was listed before the rule that changed the noun.

I’m not really sure if “convert” runs all the rulebooks that “try” does - I’ve never looked into it.

I know that I’ve had situations where I really don’t want to run all the rules for the new action, but I can’t remember what they were. But dealing with this sort of complicated rule interaction has made me extremely wary of Before rules. They almost always end up preempting some important Instead rules.

I try to avoid using Instead rules when more than one object might be affected, especially in extensions, but sometimes I want to catch a lot of different actions. Lately I’ve been experimenting with adding the same rule to multiple check rulebooks instead. But there are still times, even in extensions, when I decide to use Instead rules. And there are still times when I regret it…

What’s your approach?

I always say “instead try …”. It’s simple and it invokes all the code that the action should.

The only down-side is that if several redirects chain (and I chain plenty of redirects), it can eat stack space quickly. Heliopause has trouble on old interpreters because they allocate a small Z-machine stack.

Uh oh! I never thought I might run out of stack space. The extension I’m working on does a whole lot of redirecting.

This sounds like incredibly useful information to know. Are these kinds of rules-of-thumb documented anywhere? I’ve seen lots of useful tidbits like this but I’ve had to go through tons of threads to get many of them.

On the other hand, I find a lot of these limitations stem from Z-machine usage and yet it seems Inform provides for the Glulx format which obviates any need for someone to be worried about such things. Since Glulx has apparently been around for quite a few years now, I’m assuming people would adopt that rather than deal with Z-machine limits. Is that an accurate assumption on my part?

There has definitely been pressure to use Glulx more, but there are still interpreters being used that don’t support it. I think many mobile device interpreters are z-machine only, and I’ve heard that the new Kindle interpreters are also z-machine only.

Some people have been taking a dual-release approach, with some extra features (such as more robust parsing with more helpful error messages) added to the glulx-only release.

I think people do.

In the case of Heliopause, my decision to stick with Z-machine was based on two considerations. One, Quixe was not (quite) finished at that point (last June). And two, this was only a marginal restriction – it only affected a few extant interpreters. (Properly it’s a limit on a given implementation, not on the Z-machine design itself. I ran into the limit on iPhone Frotz, which has since been upgraded to have a larger stack.)