An action is what a mathematician or computer scientist would call a 5-tuple, n-tuple being how mathematicians and computer scientists say “made up of n parts which, in combination, uniquely identify the tuple, i.e., if the values of all n parts for both X and Y are the same, then X and Y are identical: they both identify the same tuple.” Unless they’re feeling really inscrutable, in which case they might say instead that an n-tuple identifies a vector in n-dimensional space.
4 of the 5 will be very familiar:
- the actor
- the action name (e.g., waiting, opening, throwing it at)
- the first argument, e.g., noun
- the second argument, e.g., second noun
- whether the act was requested
If you turn on the actions debugging command and say “bob, go north”, the output will describe it as “asking Bob to try going north” as if the player is the actor and “asking it to” is the action name and Bob is the noun, and “going north” is… something.
But asking it to isn’t really an action in the same sense as other actions, the compiler just plays some tricks to pretend that it is. The action that really results from ``bob, go north` has Bob as the actor, going as the action, and north as the noun from the start. But it also has action requested: true. If persuasion succeeds, the carry out requested actions rule transforms this into Bob’s action just by flipping action requested to false. Then Bob’s action is attempted and when it’s over, we restore the old action requested and conclude the player’s asking it to action.
Rule preambles can have descriptions of actions, but to assign an action to a variable or table column, you have to uniquely identify a vector in action-space by providing enough information for Inform to know all 5 values. We don’t usually think of it anything like that, because so many are implicit.
If you leave out an actor, the player is assumed, so for actions applying to nothing, their action names alone serve as fully-specified actions: thinking is yourself thinking. For things that take one argument, you need to specify it; for things that take two, you have to specify both. For requests, you would say, e.g., asking bob to try going north, uncoincidentally just like how actions’ output has it.
But you could simulate allowing specifying location by having another room-valued column, and if it’s not blank, your code tests whether both the action matches and the room gone from (if that’s the one you mean) matches the location in the table.
[ edited: erroneously said asking it for instead of asking it to in a couple places. They’re different action names. asking it for is the action name of the current action briefly when you, e.g., ask bob for spoon, but then the action is promptly converted to the same thing you get with bob, give me spoon, i.e., asking bob to try giving spoon to yourself. ]
[ edited further 'cause my inner pedant can’t stop: if you look up stored actions, you’ll see there are six parts, one being the text of the player’s command. If an action applies to a topic, then the topic understood is a snippet variable, and snippets only have meaning in relation to some particular command text, so Inform stores the command text itself instead of a meaningless snippet value. But those are all implementation details; conceptually the topic is just another argument, either first or second, and so I assert that it’s reasonable to describe actions in the abstract as a 5-tuple. ]