But I WANT to "decide on nothing"

Authoring Inform 7
1

OK, so maybe I’m still thinking as a coder sometimes, and have yet to master the zen of Inform 7…

But often I DO want to “decide on nothing”:

stuff like this (in I7-flavoured pseudocode):

    to decide which AAA is the BBB:
        if CCC:
            decide on DDD;
        decide on nothing;

Basically, I’m using “nothing” as a null type, but Inform won’t let you do this - you are not allowed to “decide on nothing”.

Question (1) Is there another pattern to use in these kinds of situations so you don’t need to decide on nothing?

And (2), is there a reason why you’re not allowed to decide on nothing?

And (3), am I likely to break anything if use this workaround:

definition: a thing is nonexistant: no.

to decide which thing is nothingness:
	decide on a random nonexistant thing;

That is, with that snippet, whenever I feel the urge to decide on nothing, I just “decide on nothingness” instead and everything seems to work just like if I could decide on nothing.

2

You can do something like this (from ATTACK):

The stand in for no one is a person variable. The stand in for no one variable translates into I6 as "nothing".

Note you generally then need to check whether the decision is the stand in for no one. If you don’t things will break. You could leave out the translates into I6 part - all it does is save you a little memory by not defining an object.

3

Not a problem. All you need to do is use the syntax “to decide on which object”, which will return an object. As “nothing” is an object, deciding on nothing will work.

4

Or you could define a special dummy AAA and decide on that instead of deciding on nothing. Then make sure you treat that dummy appropriately. (I’m really surprised that “decide on a random nonexistant thing” isn’t producing runtime errors, which “a random foo” usually does when there are no foos.)

(Also it’s “nonexistent.”)

Anyway I believe the underlying idea is that “nothing” is an object rather than an AAA, and if you try to plug it in when Inform is expecting an AAA you’ll have type clash issues (if that’s the word). I think older versions of Inform used to not enforce these type safety concerns as much, which led to fewer compilation errors and more run-time errors – can experts confirm that?

5

Hm. OK. I see.
I think I’m going with something like this. It’s not actually defining different null objects, you get the “real” nothing and can test for it. This is consistent with other I7 behavior, like doing “let P be a random person in the Forest” - either it’s a person, or it’s nothing.

definition: an object is nonexistent: no.
to decide which person is the null person: decide on a random nonexistent person;
to decide which thing is the null thing: decide on a random nonexistent thing;
6

Edit. Actually, no. This does not work the way it should. I’ll go with matt’s idea anyway.

7

This is the official recommendation. Each type has a “default value”, which for object subclasses is the first one defined, and it’s easiest to use that as your dummy. (It already appears as a dummy in declarations like “GlobAAA is an AAA that varies.”)

Or you can use this, which simply skips the type-check:

To really decide on nothing: (- return nothing; -).

This works for simple cases, like above. (It’s safe to write “if the BBB is nothing…” even though BBB is an AAA-typed function.)

It’s possible that the trick will cause run-time errors in more complicated functional code. I haven’t tested it with map or higher-order functions or anything crazy.