Strictly speaking, a description is a predicate: it’s a function that takes a value (of some sort) and returns true or false. “Open containers” is a description of things, which means it’s a function that takes a thing and returns true if it’s an open container and false if it isn’t.
But mathematically, predicates and sets are pretty close to two ways of looking at the same thing! (I want to say they’re isomorphic but I don’t know if that’s actually true in modern set theory so hopefully an actual mathematician can correct me.) “The set of all things that are open containers” and “a function that looks at a thing and says if it’s an open container” are two different ways of describing, well…which things are open containers.
The result is that there are basically two things you can do with a description, in Inform. You can test if some value fits the description, and you can iterate over all values that fit the description. (With an asterisk: only if you can iterate over that kind of value to begin with. You can iterate over things, so you can iterate over open containers. You can’t iterate over real numbers, so you can’t iterate over positive real numbers.)
But, these are two very useful things to be able to do! Every time you say “repeat with the item running through people in the location”, you’re using a description. Thanks, descriptions!
I think of it as three. (Two of them are iteration, so you’re not wrong, but it’s three pretty distinct cases.)
Checking whether an item fits a description:
if the noun is a DESCRIPTION…
Checking something about all items that fit a description:
if all DESCRIPTION are in the sack…
if all DESCRIPTION are lit…
Doing something to the items that fit a description:
now all DESCRIPTION are in the sack;
now all DESCRIPTION are lit;
Now that I think about it, this is also pretty common: selecting a random item that fits the description:
let X be a random DESCRIPTION;
There’s more fun to be had with words other than “all” – you can talk about “most open containers” or “no open containers”, which have the intuitive meaning. But the above are the common ones.
I didn’t read that whole post that you linked to. It was very long.
I do seem to recall the concept of inventory vs. what I think of as “deep inventory” to be a challenging problem, not just in IF but in OOP in general, things like checking if two objects, which consist of multiple parts and nesting, are truly equivalent to each other. Perhaps a deep_inventory() function of some sort might be helpful, something that searches the entire subtree of a given object in the object tree, but it might be a bit computational intense, depending on how many objects need to be checked and how deep the nesting goes. I don’t know enough about the inner workings of Inform to know if I am suggesting something absurd or not, I just know these types of problems aren’t as straightforward as they initially appear.
Or To decide if. They all act like predicate functions (sometimes called a boolean function). Deciding on yes or no is the Inform phrase equivalents to returning true or false. Also, you can only use Definition: for set-descriptions. Once again, I am getting all of this from Inform 7 for Programmers.
I’ve been informed that yes, you can “identify any set with its indicator function” and “any predicate can be identified with the set of elements on which it returns true”. So indeed, descriptions are sets!
I haven’t used it either but I definitely will in the future. Most of my rule preambles use the location global variable and look like this:
Check washing when location does not contain a water-providing thing (this is the need water to wash rule):
Which leads to the question: is there an equivalent phrase for the opposite of in the presence, like what I could use for the example above, where the absence of a thing in location fulfils the preamble requirements?
This is an error in the docs. in the presence of x tests whether x is in scope.
This code:
lab is a room.
parlor is north of lab.
after deciding the scope of the player: place the parlor in scope.
before doing anything in the presence of the parlor, say "Present and accounted for"
outputs:
Present and accounted for
lab
>
WI 18.29 refers to this correct meaning of in the presence of.
this could be just when the x is not in the location.
Just for fun (?), these are all the phrases definitions in the standard modules (in the current development version) that take descriptions as arguments:
Basic Inform
To let (t - nonexisting variable) be (u - description of relations of values of kind K to values of kind L):
To decide which arithmetic value is total (p - arithmetic value valued property)
of (S - description of values):
To repeat with (loopvar - nonexisting K variable) running through (OS - description of values of kind K) begin -- end loop:
To decide which number is number of (S - description of values):
To decide which K is a/-- random (S - description of values of kind K):
To decide what list of Ks is the list of (D - description of values of kind K):
To decide whether (val - K) matches (desc - description of values of kind K):
To decide what list of K is the filter to (criterion - description of Ks) of (full list - list of values of kind K):
English Language
To say regarding (D - a description of objects):
Standard Rules
To say a list of (OS - description of objects)
To say A list of (OS - description of objects)
To say list of (OS - description of objects)
To say the list of (OS - description of objects)
To say The list of (OS - description of objects)
To say is-are a list of (OS - description of objects)
To say is-are list of (OS - description of objects)
To say is-are the list of (OS - description of objects)
To say a list of (OS - description of objects) including contents
To group (OS - description of objects) together
To group (OS - description of objects) together giving articles
To group (OS - description of objects) together as (T - text)
To filter list recursion to (D - description of objects):
To move (O - object) backdrop to all (D - description of objects)
To decide which object is best route from (R1 - object) to (R2 - object) through (RS - description of objects), using doors or using even locked doors:
To decide which number is number of moves from (R1 - object) to (R2 - object) through (RS - description of objects), using doors or using even locked doors:
These don’t include Zarf’s examples of if the noun is a DESCRIPTION…, or now all DESCRIPTION are lit, because the parts after if and now are sentences, and the name for a sentence as argument is condition.
Perhaps worth noting is that you can say:
[as an imperative sentence within a code block]
now all open containers are lit;
now all open containers are in lab;
[as an assertion outside a code block]
all containers are in lab.
but you can’t say either of:
all open containers are in lab. [won't compile]
all containers are lit. [won't compile]
In assertions, all can only be used with a kind name, not a description. And you can’t assign properties with an all assertion.
all open containers are in lab. [won't compile]
all containers are lit. [won't compile]
I notice that you can say “A container is usually lit,” but not “A container is usually in the Lab.” The error message for the latter says it’s to avoid ambiguity, but it’s not obvious why it’s any more ambiguous than the first case.
There is also a really interesting part in this section after all the examples:
But we shall later see that we can also use three other tenses, not to mention plural forms, so that new verbal forms like “had not been inside” and “were not supported by” are legal here (which they would not be in assertions).
I suspect this has something to do with sentence verbs, which won’t be discussed until WI §13.1 Sentence verbs, but this level of conditional granularity seems impressive. Does this mean that Inform 7 keeps track of all the different states of object properties and relations data throughout the lifetime of a given game session, or am I reading too much into this functionality?
It doesn’t do that in the general case. Including a condition in your story that tests a past condition causes the compiler to create code that tracks that condition.
An exception is “if we have the ”. Inform does keep track, in the general case, of whether a given action has ever succeeded while a given object was the noun. This is independent of who the actor was, so the “we” is a little misleading.
Inform has the adjectives “recurring”, “non-recurring” and “happening” all built in to describe scenes…
And while the scene adjectives recurring and non-recurring show up in the Kinds index for scene:
happening does not. I assume this is because recurring and non-recurring are either/or properties associated with scenes:
A scene can be recurring or non-recurring. A scene is usually non-recurring.
While happening is a complex adjective, the result of calling a boolean (i.e. predicate) function:
Definition: a scene is happening if I6 condition "scene_status-->(*1-1)==1"
says so (it is currently taking place).
This isn’t specific to scenes, it’s just something I had not noticed until now, that complex adjectives are not automatically documented in the Kinds index.
