"Described action"

If you try to compile something along the lines of:

The trick action is a stored action that varies. The trick action is the action of burning an unlit torch.

you get an error message that’s a little intriguing:

Problem. The sentence 'The trick action is the action of burning an unlit torch'   tells me that 'trick action', which is an action that varies, should start out with the value 'action of burning an unlit torch', but this is a described action and not an action.

I take it that a “described action” is the term given to the construction for rule preambles that allows things like:

Every turn when the current action is burning an unlit torch:

Does anyone know of anything that explains “described actions” in more detail (for example, one of the Internal/*.I6T files)? The built-in documentation and Standard Rules don’t seem to mention this.

I got it to compile like this:

The trick action is an action that varies. When play begins: now the trick action is burning a torch.

I don’t know if it will work for you without seeing more of the code.

I appreciate the reply, HanonO, but my question wasn’t how to get something to compile. I was interested in more detail on what constitutes a “described action” as mentioned in the error message.

It seems like the difference between an action (or a stored action) and a described action is that the described action allows you to put conditions on the objects involved in the action. As an illustrationof the difference, your example code creates an action, but if it’s replaced with:

When play begins: now the trick action is burning an unlit torch.

then the problem message produced is:

Problem. In the line 'now the trick action is burning an unlit torch'  , you seem to be asking me to put a described action into an action, which can't safely be done.

which again shows that the compiler has a definite idea of a “described action” being something different from a regular action or stored action.

I’m very curious about this since it would be great to be able to create the equivalent of a stored described action. That doesn’t seem to be a feature of 6M62, but I was a little hopeful it might just be an undocumented feature that could be used/abused with enough poking around at the lower levels.

All right then. Back into the shadowy corner I go!

Boldly stepping out of the shadowy corner, I suspect that “described action” isn’t actually an internal thing, but this is just a way for the error message to express the idea that you have to be more specific–just as you can’t say “Now the player carries a torch” if “torch” is a kind. (BTW, Hanon, if torch is a kind I’m surprised that your thing compiles–it doesn’t seem specific enough.)

One thing I thought about was whether you could hack something up using a description of stored actions as in §22.2–make the trick action a description of stored actions, and say something like “The trick action is stored actions whose action name part is the burning action and whose noun part is an unlit torch.” But I can’t figure out how to get Inform to understand this.

I think there’s a functional difference between an assertion like “now the player carries an unlit torch” (or an attempted action like “try the player burning an unlit torch”) and a description of a stored action (which I agree is a good way to characterize the functionality I’m seeking).

Your suggestion on how to structure something like it was interesting. It makes me think that what I’m really after is the ability to store a description into a variable of some sort, as in:

which the compiler has no complaint about, surprisingly. But it doesn’t seem like there’s a way to modify the (empty?) description at run-time. As examples:

gives problem message: “Problem. In the sentence ‘now the spec is an unlit torch’ , it looks as if you intend ‘the spec is an unlit torch’ to be a condition, but that would mean comparing two kinds of value which cannot mix - a description of things and a thing - so this must be incorrect.” (This message appears whether a torch is a specific thing or a kind of thing.)

and trying with just adjectives alone, like:

gives problem message: “Problem. In the sentence ‘now the spec is unlit’ , it looks as if you intend ‘the spec is unlit’ to be a condition, but that seems to involve applying the adjective ‘unlit’ to a description of things - and I have no definition of it which would apply in that situation. (Try looking it up in the Lexicon part of the Phrasebook index to see what definition(s) ‘unlit’ has.)”

For the second example it looks like the compiler is treating “now … is” as meaning an attempt to assign the unlit property, not define the conditions of the description of things.

Descriptions are a meaningful data type in Inform. However, it’s one of those types which exists only to glue I7 literal code to I6 library functions.

When you write “move the sun backdrop to all outdoor rooms”, you’re invoking this phrase from the standard rules:

To move (O - object) backdrop to all (D - description of objects):
        (- MoveBackdrop({O}, {D}); -).

“all outdoor rooms” is a description literal, but you can’t just stick it in a variable. When Inform sees a description around an “is” verb, it tries to read it as part of an assertion. (E.g. “all outdoor rooms are frozen”, etc.) I don’t know exactly how “conditions” come into it but they’re in there somewhere.

Now, there’s a cheap trick you can use for Inform literal types:

To decide which description of things is literal (D - description of things): decide on D;

Now “literal all outdoor rooms” is a description value, and Inform won’t try to be clever about reading it as a condition or whatever. So “now the spec is literal all lit torches” will work.

But then what do you do with the spec? You need I6 code to do anything interesting with a description value. Poking around in the I6 is left as an exercise. :slight_smile:

In fairness you can do some interesting things with descriptions from I7. For example you can get “the list of [a description]”, or print it. But yes, their main raison d’être is to be passed to I6 functions.

That seems in tension with the discussion of descriptions in §22.2 of Writing with Inform:

That last bit very much suggests that it should be possible to store a description in some variable. And, as otis has already discovered, you can define “description of K” variables. But I can’t figure out a syntax for setting them. §22.2 gives as sample descriptions “even numbers” and “open containers which are in dark rooms”–but if you try something like:

The trick action noun is a description of objects that varies. The trick action noun is open containers which are in dark rooms.

you get the following error message:

Which I guess is the compiler telling us to back off.

OK, I was going to use zarf’s trick to try something along the lines of what I thought otis had in mind, storing the trick action in parts so we could check the noun against a description to see if it matched, like this:

[code]The cave is a room. A torch is a kind of thing. A torch can be lit. Five torches are in the cave. Understand the lit property as describing a torch.

Instead of burning an unlit torch:
now the noun is lit;
say “You light the torch.”

To decide which description of things is literal (D - description of objects): decide on D;

The trick action name is an action name that varies.
The trick action name is the burning action.
The trick action noun is a description of objects that varies.
The trick action noun is literal all unlit torches.
The trick action second noun is a description of objects that varies.

Every turn when the current action conforms to the trick action: say “Trick action performed.”

To decide whether (act - a stored action) conforms to the trick action:
if the action name part of the action is not the trick action name, no;
unless the noun part of the action is nothing or the noun part of the action matches the trick action noun, no;
unless the second noun part of the action is nothing or the second noun part of the action matches the trick action second noun, no;
yes.[/code]

But the complier didn’t like zarf’s trick:

So… I dunno.

But the complier didn't like zarf's trick:

Since it is a function, it has to be executed, which cannot be done at compile time. You can do it in a when-play-begins rule.

Thanks!

OK, here it is cleaned up. I fixed some other errors–like, I failed to use the variable name “act” at all, I mixed “description of objects” and “description of things,” and also it didn’t work to put the test in an Every turn rule because by the time the rule fired the noun was always a lit torch. Also it turns out the word “all” isn’t necessary. So:

[code]The cave is a room. A torch is a kind of thing. A torch can be lit. Five torches are in the cave. Understand the lit property as describing a torch.

Instead of burning an unlit torch:
now the noun is lit;
say “You light the torch.”

To decide which description of objects is literal (D - description of objects): decide on D.

The trick action name is an action name that varies.
The trick action name is the burning action.
The trick action noun is a description of objects that varies.
When play begins: now the trick action noun is literal unlit torches.
The trick action second noun is a description of objects that varies.

Before doing something when the current action conforms to the trick action: say “Trick action commenced.”

To decide whether (act - a stored action) conforms to the trick action:
if the action name part of the act is not the trick action name, no;
unless the noun part of the act is nothing or the noun part of the act matches the trick action noun, no;
unless the second noun part of the act is nothing or the second noun part of the act matches the trick action second noun, no;
yes.[/code]

So, it’s not super pretty, but maybe it accomplishes something!

Unfortunately, descriptions can’t be put in tables, which might provide a way to streamline some of the stuff that one might try like this. I suppose if I were in a position where I wanted to put this description in a table, what I’d probably do is make a rule-valued column, where each referenced rule set a global variable to the description of things I wanted. Pretty kludgey!