You can think of it as syntactic sugar around something like…
Exactly this. Giving properties to colors is effectively making an array indexed by the color—this is exactly why you can give properties to enumerated kinds of value but not numerical kinds of value (i.e. you can’t attach properties to ints or floats), because that would require an impractically large array.
In other words, “a color has a number called hue” and “the hue of red” is the equivalent of int hue[N_COLORS]; and hue[RED].
(This is, in fact, pretty close to how properties of objects work too. In a language like C, there’s a big difference between a struct and a global array: you can make new structs on the stack or the heap and pass them around. In Inform, by default, you can’t do that. The number of objects is known at compile-time. So some properties are actually part of the memory block that the “object” points to, and some of them are stored in big arrays indexed by the “object”, and the I7 user never has to know or care which is which. Relations and route-finding things especially use the “big array” approach.)
From an I7 vantage point, enumerated kinds of value are kinda like objects, but each kind of EKoV is its own class, with no possible sub-classing.
Named values can be used almost anywhere an object can.
The differences are chiefly described in WI 11.18.
Then there are a bunch of grotty differences in the details…
pathfinding only works for relations of objects
only objects can be in scope… but EKoVs can be used as tokens. So in terms of how the parser deals with stuff, the granularity of objects is on a per-object basis, but for EKoVs it’s per-class – the parser will either accept any value of that EKoV in a given place or none of them
an action can act on multiple objects, but not multiple values of some EKoV
to act on an EKoV, an action specification can and must specify that EKoV; in 10.1 and earlier, to act on an object, you must say thing which means… object. In the forthcoming v11, you’ll be able to name a particular subkind of object… except that thing will continue to mean any object for backwards compatibility
a bunch of obvious things like that the spatial relations are relations of objects, so only objects can be in the game world
some less obvious things like the indefinite article machinery only works with objects
I’m sure the above is incomplete.
Edited to add: Thought of another. Actions can apply to nothing, or to one thing, or to one thing and one non-thing (whether EKov, number, topic, whatever), or to two things, but they cannot apply to two non-things, thus, an action cannot apply to two EKoVs.
More specifically this is about a type of value called a sayable value. These are values that have some sort of text representation such that if you use a say phrase on them, something will print out:
say "[(sayable value)]"
Another type of value, enumerated value, was introduced in the previous chapter.
According to Inform 7 for Programmers, there are six different values, also known as generic types:
arithmetic value
pointer value
word value
sayable value
enumerated value
value
We haven’t yet encountered arithmetic or pointer or word values in this documentation, but I will be keeping my eye out for when they appear.
Arithmetic values do get documented (they’re sort of the opposite of enumerated values) but I don’t believe word values and pointer values are ever mentioned in the documentation. They don’t really matter in I7, only in I6—I7 works hard to avoid exposing them to the user directly.
Yeah, “description” is a bit of an overloaded word in Inform 7 because it can refer to both the description property of objects – which is really important for the content of your game world – as well as describing a list of data entities – also, an extremely important and powerful feature of Inform 7. Two very different, important pieces of Inform 7 with the same name.
I now think of this second type of description as a “set-description”, yet another name used in Inform 7 for Programmers. You provide one of these set-descriptions and it finds a list of zero or one or more data entities that fulfill those set-description requirements. I assume it is always an actual set that is returned – a list with no duplicates in it – but I don’t know if this is true or not.
If the game world is the database, then the set-description is the query language that allows you to pull together a precise of list of data (usually objects) for you to use. It’s like Inform 7 has its own little SQL relational database built right in.
Yeah, I figured parts of Inform 7 for Programmers are outdated and I appreciate everyone helping me out, identifying those parts.
For me, Inform 7 for Programmers was the document that helped me finally start to really understand Inform 7, outdated or not. So, I am glad to continue referring to it and to also getting everyone’s valuable feedback on those references as well. Sort of like getting two manual reviews in one .
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.
.