Accessing truth states via (T - a truth state)

Authoring Inform 7
1

I’ve discussed the following issue in private with Draconis, in relation to his Booleans extension (it basically uses objects as truth states) but I’m returning to it anew to see if there’s a way around a certain issue.

Background - This extension I’m making has so many switches the author can set, I wanted to include a better way to set them.

I have some objects which carry multiple truth states, and you can ‘tick (object)’ or ‘cross (object)’ to turn all its states on or off at once. There are also 3 custom phrases for turning individual switches of these objects on or off.

But then I still have a ton of plain old truth state switches separate from these objects.

My ideal goal would be to have the commands ‘tick’ and ‘cross’ work on the objects, but also on any truth state variable as well, so that authors wouldn’t have to pay attention to which were which.

So I have object phrases like this:

[code]To tick (H - a hotkey option) menu:
now menu of H is true;

To tick (H - a hotkey option):
tick H support;
tick H hotkey;
tick H menu;[/code]
And a fall through phrase intended to catch regular truth states, like this:

To tick (T - a truth state): now T is true;
The phrases intercept and identify the correct things (hotkey objects or truth states) but then I realised that in the truth state case, T isn’t returning the truth state variable, it’s returning the true or false setting of T, so it doesn’t work.

Question - Is there any way to make the truth state phrase work as I intend?

If not, I could make all the variables in the extension tickable/crossable boolean objects but then the player can’t ‘tick’ their own variables, and they start to run into that ‘I need to remember which is which’ issue. Of course it’s not an error that goes undetected, because the program just stops compiling if you use the wrong one. But it’s annoying, and is not intuitive.

One alternative I thought of is: make only the special objects that carry multiple truth states tickable and crossable (their fewness and their context makes them easy to remember). But that leaves a mountain of truth states brought by the extension which just have to be set by ‘now (blah) is true’, still giving two different ways to do things in an area (CYOA variables) where one would be more logical.

-Wade

2

I don’t think so. Consider this program:

Mandatory Room is a room.

sum is a number that varies.

myflag is a truth state that varies.

To increment (N - a number):
	now N is N + 1;
	say "in increment phrase: N is [N]."

To tick (T - a truth state):
	now T is true;
	say "in tick phrase: T is [T]."

when play begins:
	now sum is 42;
	say "before increment: sum = [sum].";
	increment sum;
	say "after increment: sum = [sum].";
	now myflag is false;
	say "before tick: myflag = [myflag].";
	tick myflag;
	say "after tick: myflag = [myflag].";

It produces this output:

This is pretty clear evidence that primitive types like numbers and truth states are passed to phrases by value rather than reference. This means that the phrase receives a copy of the variable and, regardless of how it changes that copy, the original is left unchanged. So why can phrases modify objects in a persistent way? Because, in that case, the variable that is passed by value is a reference to an object (i.e., a number that refers to the object, as in “object number 23”) that can be used to access and modify the object from anywhere.

I think the solution is to wrap your primitives in actual objects and use them instead.

1 Like
3

Le sigh!

-Wade

4

You can get around the pass-by-value issue by using an inline I6 definition:Foo is a room. Blah is a truth state that varies. To tick (T - a truth state): (- {T} = 1; -). When play begins, tick blah.Of course, you do this at your own risk: it will work for global variables, but for example will give you an I6 error for properties. There is an undocumented syntax that allows you to make an inline I6 definition that applies only to global variables, but as far as I know it can’t be combined with a specification of the variable’s kind (so that Inform would allow you to apply the phrase to a scene global variable, for example, which could lead to very confusing runtime behavior). I don’t know any way to achieve the ideal situation of Inform only allowing the phrase to apply to truth state-valued global variables.

1 Like
5

There’s a syntax for taking properties as a parameter (see Standard Rules SR5/2/4 for example), so maybe that could be used in conjunction with inline I6 to get the correct effect on properties?

To tick (T - a truth state valued property): (- ...whatever... -).
6

I strongly recommend you not try to hack this plan into working. It will cause you pain.

7

Thanks all. I intend to stick with I7 and make some decision about where/how I apply the original idea.

-Wade

8

A very old post, I know, but the phrase

To tick (Z - truth state):
    (- {Z} = (+ true +) ; -).

seems to work as desired in 6M62.

1 Like
9

Thanks. I recall that in that situation, I went with the booleans mentioned earlier in the topic.

-Wade