Activity variables disappear when manually handling them?

Authoring Inform 7
1

It doesn’t seem like this should be intended behavior, but I can find no reference to it on the bug tracker. I’m just checking here first.

Basically, when beginning an activity manually, the before rules are run as documented, but the activity variables created can’t be referred to in the handling code. This works as expected:

Lab is a room.

Fooing something is an activity on numbers.
The fooing activity has a number called bar.

Before fooing a number (this is the setting activity variables for fooing rule):
	now bar is 1;
	say "(Setting activity variable 'bar' to [bar]).".
		
For fooing an odd number (called target):
	say "The 'For fooing rules for odd numbers' states that the bar of [target] is [target] + [bar].";
	now bar is target + bar.

After fooing a number: say "Fooing activity completed with value [bar].".

Instead of waiting:
	carry out the fooing activity with 3.

But when I add this, compilation fails because the activity variable “bar” isn’t recognized.

Instead of saying yes:
	let target be 2;
	begin the fooing activity with target;
	if handling the fooing activity:
		say "Manually taking over the fooing activity for [target]. The bar of [target] is ";
		say "[bar].";
	end the fooing activity.

test me with "z / y".
1 Like
2

That seems undesirable, but also understandable: generally, activity variables can only be accessed by rules in that activity’s rulebooks, right?

3

I understand that activity variables are local; the documentation is clear that they “are visible to the rules for that activity, and nowhere else.”

But in this case, the documentation implies that the activity is being run and that the handling code acts as a proxy “for” rule.

From WI §18.7 Beginning and ending activities manually:

This time the activity is ongoing throughout as many phrases as we care to write between the “begin” and “end”. The before rules are considered at the time of the “begin …” phrase; the after rules at the “end …”.
[…]
We place the activity’s normal behaviour inside the “if”; the condition, “if handling…”, is true only if no rule has intervened. This means that we (or other authors using our activity) can create their own for rules to substitute here.

While I understand why the variables aren’t exposed, it seems like that should at least be documented more clearly.

1 Like
4

Just a thought, but… does say "[bar of the fooing activity]" or any similar phrasing work?

5

The contents of an if handling <activity> activity conditional being a sort of proxy for <activity> rule is a good description of the mechanism’s effect… and yet, as you’ve seen, it’s not really a for <activity> rule and it doesn’t acquire for <activity>-rule-powers.

(I think the underlying I6 activity management model’s design is a good one. In context, it makes sense to have fallback code in case the I7 didn’t specify any for rules. What WI 18.7’s phrases provide is the means to mimic the underlying model, doing what it does in I7. But if you’re working in I7… you could just specify a for rule. I’ve never found a use case for them.)

6

I don’t think the compiler is prepared to handle bar of the fooing activity, though this is close cousin to a rulebook variable, so it might not be much of a stretch to make this possible. (@Celtic_Minstrel or @Zed might be able to answer definitively about whether it’s possible to get at this with some obscure syntax… or even whether that might be something that could be enabled with a bit of Preform, using how rulebook variables are handled as a model.)

It is possible (though a little ugly) to get at the values for currently-executing activities from outside their rulebook with some I6 hackery.

1 Like