Tiny Inform Gotchas

Today I learned two things about Inform 7. (I wish I hadn’t had to learn either of them.)

First, if you want to move a backdrop, the syntax is different than for other things. If the sky is a backdrop and you’ve defined a room property called “outdoor”, this doesn’t work:

When play begins:
     move the sky to all outdoor rooms.

You have to do it this way:

When play begins:
     move the sky backdrop to all outdoor rooms.

There’s no reason why you should have to include the word “backdrop” there. The compiler already knows the sky is a backdrop. But you have to do it anyway.

Second, “holds” doesn’t mean what it should. Inform lets characters have possessions in two ways: things can be worn or carried. The two conditions are different, so if the character is wearing a hat and you test “if John carries a hat,” the condition will fail. However, if you test “if John has a hat,” the condition will be true whether he’s carrying it or wearing it. The gotcha is that “holds” is a synonym for “has.” It ought logically to be a synonym for “carries,” but it’s not. If you’re wearing something, you’re not holding it — except in the world of Inform 7.

I’m mentioning this stuff for two reasons. Primarily, it’s a memo to myself, and to anyone else who happens to be using Inform. But also, these may be good examples of the kinds of tangles you can get into when you set out to create a “natural language” computer programming system. “Natural language” programming (and yes, I will continue to put quotes around that phrase) more or less invites the programmer to actively misunderstand what’s needed.

It’s not that “move” means the same thing with respect to backdrops that it does with respect to other objects. Clearly it means something different. In a C-style programming language, we might have something like sky.distributeTo(), which would be an obviously different method from topHat.moveInto(), because the top hat is only going to be in one place at any given time. On the other hand, a standard .moveInto() method would be meaningless for a backdrop, because it’s in lots of places at once, so the backdrop class could transparently override .moveInto() rather than providing a separate .distributeTo() method. Or it could remap .moveInto() to .distributeTo(), allowing the programmer to use whichever call she happened to think of.

The point I’m getting at is, once Inform has let you use the word “move” (or alternatively, the syntax “now the sky … is in”), forcing you to tack on the word “backdrop” doesn’t clarify the nature of the method that is being invoked. It’s just … well, we can’t call it syntactice sugar. It’s syntactic garlic.

Nor are these isolated examples. Here’s another: If you want an object to be mentioned in a specific way in a room description, you can create a “Rule for writing a paragraph about…” the object. But what the game is doing is not, in fact, writing a paragraph about the object — it’s printing a paragraph about the object. I’m the writer. I wrote the paragraph. Needless to say, the syntax, “Rule for printing a paragraph about…”, doesn’t work.

This is why I always put “natural language” in quotes. What Inform uses is not natural language. It’s a particular programming syntax disguised as natural language, and that’s all it is. Someday we may be able to write computer programs in natural language, but at a guess, that day is still at least a decade in the future. It’s an enormously complex challenge.

This entry was posted in Interactive Fiction and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s