Inform 7: a model for pedagogical programming?

by T R G Green
University of Leeds, UK

I was recently intrigued and inspired by Inform 7, a new programming language/environment, originating entirely outside the PPIG and human-centered computing communities but dominated by the same ideals of ease of use in every possible aspect. I have not seen such thoroughgoing dedication since the days when Eisenstadt and Lewis (1992) analysed every single user error ever made in their pedagogical language SOLO. What can we learn from it? Can we adopt similar techniques for other purposes?

Inform 7 (see references) is the first programming language I have encountered that makes a serious attempt to be like English or any other natural language (that might just mean I'm ignorant of what's going on, of course). Moreover, it is a working, publicly available, well-used language. Being 'like' English does not mean literal translation as in AppleScript or Cobol. Inform 7 is far more sophisticated, using some of the techniques for discourse understanding that people normally use. More of this below.

Graham Nelson (2006), the creator of Inform, consciously and explicitly addresses a wide variety of learner difficulties. All the following will be familiar to PPIGers (and are therefore unreferenced). The syntax of programming languages is unforgiving and arcane; they demand understanding of many new concepts and skills that relate only to the world of programming, not to any other world; variables and loops, the stuff of life to an procedural programming language, are known to be difficult concepts for learners; the natural strategies of problem-solving seem to be different from what can readily be done in a typical programming language; the tools of programming (the IDE as a rule) usually make additional problems for learners; and most people find the standard example problems are dull and meaningless, so motivation suffers.

Inform 7 attempts to remove or diminish all of those problems. In many cases the goals stated by Nelson, and the reasoning given, are very close to the desiderata that emerged by Pane et al.'s study (2001) of natural programming strategies.

The computational linguistics techniques used in Inform 7 are not novel, as far as I know. What is novel is that such techniques have been put to practical use, and have worked. Previous Inform versions won't be mentioned, so for convenience I shall henceforth use 'Inform' to mean 'Inform 7'.) The book metaphor used for the IDE, sketched below, may or may not be novel; but again, the important point is that it exists and has been found effective.

What follows may read like a paean to Inform. A balanced review of strengths and weaknesses would pay far more attention to the things I found difficult. That's because what I want to argue that here is, I believe, a promising line for PPIGers, and I hope to enthuse a few researchers into following its lead into new territories.

The domain: interactive fiction

Inform is a domain-specific language, which is probably essential for a system that has some background knowledge and assumptions. The domain is interactive fiction (IF), the genre previously known as text adventure games. Writing interactive fiction is somewhere between programming and writing a short story.

Interactive fiction (IF) typically presents a world with a puzzle (or sometimes a world with no puzzle, to be explored for fun). Working usually in pure text, or sometimes text with static graphics, the player explores the world through an avatar, able to see, touch, eat, hear, smell, hold, carry things; other 'non-playing' characters may appear, to be talked to, asked questions, etc. The world is usually divided into locations connected by moving in given directions -- sometimes with a few unexpected twists. Here is a scene from such a game:

Attic

The attics, full of low beams and awkward angles, begin here in a relatively tidy area which extends north, south and east. The wooden floorboards seem fairly sound, just as well considering how heavy all these tea-chests are. But the old wiring went years ago, and there's no electric light. A hinged trapdoor in the floor stands open, and light streams in from below.

From Attic the player can request to move north, south or east, or down (via the trapdoor); or can close the trapdoor, look in the tea-chests, etc. In this game, moving north brings us to a new scene, the Old Winery:

Old Winery

This small cavity at the north end of the attic once housed all manner of home-made wine paraphernalia, now lost and unlamented. Steps, provided with a good strong banister rail, lead down and to the west, and the banister rail continues along a passage east. You can see a labelled glass demijohn (which is closed) (in which are a nasty-looking red battery and a tourist map) here. As you disturb the still air, the attic key, which was balanced on top of the demijohn, slips onto the floor and disappears into a crack in the floorboards. Your spirits sink as it does, rattling down some distance. How on earth are you going to get it back?

To solve the puzzle, the player usually has to gain access to a variety of different locations, often needing specific objects to accomplish subgoals. For example, the 'nasty-looking red battery' will be needed elsewhere in this game for a torch, which will itself be needed to penetrate a dark area; and getting the key back is quite a hard problem. Things can possess a wide range of properties: they can be movable, carryable, openable, eatable, etc; they can be containers for other things, or supporters for other things; they can be part of other things, or they can be members of a set of things, and so on.

Inform as a programming language

So here is a fragment of Inform, creating a room, an object standing on another object, and an exit:

The bar is north of the lecture hall. A counter is here. It is fixed in place. The glass is on it. A daisy is in it. The barman is a person in the bar. "You are in the bar of a small university college."

Inform 'deduces' that:

  • the bar is a room
  • the lecture hall is another room (because it is south of the bar, and there's no indication that it's a door)
  • the lecture hall is south of the bar (because possible routes are usually reversible - if you can walk north from A to B, you can walk south from B to A)
  • the counter is in the bar (note that the anaphoric reference to 'here' must be resolved)
  • the glass and the daisy are things (being on top of or inside other objects means that they cannot be rooms)
  • the counter is a "supporter", a kind of thing able to hold other things up (because the glass is on it), and similarly the glass is a "container"
  • the counter is fixed in place (note another anaphoric reference, to 'it')

None of those properties are specifically mentioned, nor are they default values (although Inform does include plenty of default values: unless otherwise specified, objects are inedible not edible, for example). Inform's 'understanding' is reached by creating a model of the scene described, adding to that model as each new sentence is read. Much tedious specification of detail is taken care of, leading to statements that are succinct yet clear.

The fragment above, far from being arcane, is written in English. Inform is not arcane; nor does it require understanding of new concepts, like an object hierarchy. The fragment is surprisingly succinct, compared to the tedium of most conventional language fragments. Determiners take succinctness further. Nelson (p. 11) observes that for all its brevity, "if a person is carrying a container" is a double search, over both people and containers.

Loops and loop variables, those habitual trouble-makers, can be weeded down to minimal proportions: we can refer to "the list of things in the sack", or "if any of the things in the sack ... ". Variables used to retain state history, in conventional programming languages, can also be reduced, because Inform has access to past history and allows no less than four tenses: is, was, has been, or had been, allowing comparisons between various states.

Here is another fragment, this time illustrating how new terms can be added:

Brightness is a kind of value. The brightnesses are dim, shining, and blazing.

The example continues:

These are values, but we can create them freely, giving each of them names, just as we do with objects.

And we could then add:

A brightness can be adequate or inadequate. A brightness is usually adequate. Dim is inadequate.

Programming needs data structures. Data structures are not part of normal conversational English, but Inform adopts the standard and familiar data structure of the printed book, the table, as a powerful and familiar metaphor. The following example also shows how a new unit can be created: Height is a kind of value. 10 cm specifies a height.

Table of Average Rainfall:

Month Rainfall
"January" 20 cm
"February" 38 cm
"March" 35 cm

Of the new unit, Graham Nelson observes: "And now whenever a value from the rainfall column is printed, it's printed correctly; and type-checking prevents you from multiplying two rainfalls together (what would an area of rain mean?), and so on."

The treatment of tables is designed to eliminate index variables as far as possible, since they are so problematic. Instead there are such phrases as these:

Repeat through the Table of Average Rainfall:
say "The ran in [month entry] is typically [rainfall entry]."

and

if there is a rainfall of 38 cm in the Table of Average Rainfall, say "It happened in [month entry]."

Lastly, another nice English-like feature is the definition:

Definition: a thing is tantalising if it is in a locked opaque container which the player can see.

What do you mean, 'English'?

Every dog has two ends, and they are different: input at one end, output at the other. So it is with programming languages -- and, as with dogs, we talk much more about one end than the other: we talk about reading them, but not about writing them. When I ask 'what do you mean by English?' the notorious Turing test no doubt springs to mind: but it's irrelevant here -- it's about reading words, not about writing them. (It's also completely unhelpful, since it doesn't say anything about what properties are necessary and sufficient.)

If we wish to reduce the number of what I called above "new concepts and skills that relate only to the world of programming, not to any other world", then the language must feel like English when it's being written. Inform does not, of course, allow all the strategies of speech to be used, but it does a good job. The first example above illustrates:

  • Default assumptions and background knowledge: Inform knows about persons and things, and does not need to be told; and it has default assumptions about things, such as that they are carryable, which need not be mentioned except to be cancelled (e.g. objects are assumed to be carryable, so we cancel that assumption for the counter by saying it is fixed in place).
  • Semantic inference: if a glass is on the counter, the counter must be a particular kind of object.
  • Anaphora resolution: A counter is here. It is fixed in place...."

Together these help the writer of Inform to achieve one of the Gricean maxims: "Do not make your contribution more informative than is required".

When the receiver, the person being spoken to, can perfectly well manage to figure something out, we don't demean them by stating the obvious. When we are forced to state everything in full, we have to learn new strategies.

In Inform, we can say:

Mr Darcy wears a top hat.

and we know that Inform will deduce that Darcy is a person, because inanimate objects do not ordinarily wear clothes, and that the top hat is clothing.

The properties listed above are necessary but they are not sufficient, and if you start using Inform you find soon enough that there are some new verbal strategies to be learnt. Nevertheless, they go a long way, and merely by existing they demonstrate that a programming language can be much more like English than usual.

The user experience

Some things are so beautifully made and so intriguing that we want to use them just for their own sake. Inform feels that way to me. Karel the Robot does not.

As much or more thought went into Inform's development environment as the language itself. Nelson chose to present the interface as an open book with facing pages, using the author's work (the program) on the left, and on the right its consequences, the computer's replies. Instead of treating incorrect input as an 'error' with an 'error message' (all too often, as Nelson says, nasty, brutish and short), Inform responds to 'problems' with generous messages and with guesses at how the problem arose, attempting to treat programming in more conversational terms:

Problem. There doesn't seem to be any location in this story, so there's nowhere for the player to begin. This may be because I have misunderstood what was meant to be a room and what wasn't: I only know something is a room if you tell me explicitly ('The Observatory is a room') or if you imply it by giving map directions ('East of the Observatory is the Planetarium').

Because of this problem, the source could not be translated into a working game. (Correct the source text to remove the difficulty and click on Go once again.)

The development environment includes careful documentation, well-larded with examples (over 250 at last count), each of which can be injected into the source-text pane at the press of a button. The world model inferred during the compilation phase is available to be searched in other panes - map, index of locations of things, list of defined values, etc, each with a link to its occurrence in the source text. My experiences so far have been very positive. This is the kind of care that should go into pedagogical environments.

The weaknesses aren't the point

I have plenty of criticisms of Inform; for example, its handling of small typos is sometimes abysmal. The syntax of nested conditionals continually trips me up, and there are a few irritating inconsistencies in syntactic structure. At a deeper level, I have found it extremely hard to grasp some of the distinctions, so that creating new things and values seems to be trial and error, despite the attempts made to give sympathetic, useful error messages.

None of that is relevant to my purpose, because I am not touting Inform for its own sake. I believe that although the usability problems are real enough to stand in the way of using Inform for pedagogical purposes as it currently exists, they are relatively superficial.

What does all this have to offer?

Motivation

The first language I learnt was Mercury Autocode, and the first worked example was how to tabulate Sievert's integral. Despite having perfectly good A level maths and a mild interest in reading about maths and physics, I had never heard of Sievert's integral and I didn't care tuppence. A good example of a really bad example. Today's equivalent is the sorting algorithm (yawn).

Learners need to be motivated by interesting, engaging examples, and interactive fiction might be promising. Not many people would use a tabulation of Sievert's integral as a courtship gift, but who knows, a personalised IF game might go down quite well. (In fact, there is apparently a sub-genre of erotic IF games. Bet you can't say that about Quicksort, or even Karel the Robot.)

The real point here, of course, is much more general: learners who are motivated by needing to use a language for professional work in their own domain would probably learn most happily from domain-relevant examples -- and that's just Inform's strength.

Not much to learn

Many programming languages have been created for educational purposes, with a variety of guiding principles; Inform, although not intended for educational purposes, appears to succeed in at least one their aims, minimising the new concepts to be learnt.

Quick results

Creating something small in Inform takes very little typing, compared to more traditional languages. Really big things, however, would take much more typing than in conventional languages, or so I imagine, because they would run into the areas that Inform is bad at (complex procedural programming).

Scaling

For the learner, scaling is essential; failure to scale has killed some very smart ideas. Remember HyperCard? Really easy to make your first button, fairly easy to get your first quick result, but as the program grew the problems grew too. HyperCard had poor visibility, with small interacting packets of code distributed everywhere in a document with no macro-structure, making debugging very hard work. (See Eisenstadt 1993). Consequently, HyperCard simply did not scale up.

As a learner, my first-hand experience of Inform is limited to toys: but there plenty of games of some magnitude available, and I have been assured by both Nelson and Short (personal communications) that Inform can produce "a maintainable, scalable base of code for an ambitious project" (Short, ibid). To assist, the code can be divided into parts, chapters, sections, etc, just like any other text; the world model inferred during compilation is made available; and the play of the game can be divided into scenes, starting when some condition becomes true.

Cognitive ergonomic evaluation

- or rather, lack of evaluation. All the familiar questions are yet to be answered about viscosity, hidden dependencies, and the other cognitive dimensions. But I am intrigued to encounter a new type of difficulty. What Inform understands is English, sure enough, but nothing like all English: the difficulty is knowing what's allowed, whether lexically (a device be switched on or turned on - what about put on?), syntactically (limitations abound), or semantically (what inferences does it make, and what reasonable inferences does it not make?). To date, in my limited explorations, a good deal of time has been spent on twiddling things until they work.

Possible generality

My main thrust is that Inform, with its English-based language and conversation-like environment, could be interesting for computer education, allowing learners to create micro-worlds. Need we stop there? If these micro-worlds truly scale, we could very well apply similar techniques to specialised domains of likely interest to end-user programmers. Various contexts can be envisaged. Inform can easily be imagined controlling equipment, the sort of tasks that Forth was created for. Marian Petre and Alan Blackwell have observed teenagers performing small programming tasks in social contexts, using today's social interfaces (2007). More daringly, maybe English is a candidate medium for programming home automation. In this context Blackwell et al. (2007) have studied tangible programming languages as a contrast to the familiar WIMP interface, observing that "the options for innovation when generating or evaluating new kinds of interaction can be obscured by reliance on old metaphors": programming in (near) English would make another contrast of a very different kind.

Acknowledgments

Many thanks to Drs Graham Nelson and Emily Short for reading a first draft, correcting both my code and my assertions, and making very positive suggestions. Naturally the remaining mistakes are nothing to do with them.

References

All URLs were checked in Sep 2008.

Blackwell, A.F., Morrison, C. and Edge, D. (2007). A solid diagram metaphor for tangible interaction. Paper presented at CHI 2007 workshop on Tangible user interfaces in context and theory.

Eisenstadt, M. (1993) Why HyperTalk debugging is more painful than it ought to be. In J. L. Alty, D. Diaper and S. Guest (Eds.) People and Computers VII: Proc. HCI '93 Conference. Cambridge: Cambridge University Press.

Eisenstadt, M., and Lewis, M.W. (1992) Novice programmers' syntax errors: causes and cures. In M. Eisenstadt, M. Keane, and T. Rajan (Eds.) Novice programming environments: explorations in human-computer interaction and artificial intelligence. London: Lawrence Erlbaum Associates, 1992. Available for download (gzipped postscript)

Inform (home page)

Nelson, G. (2006) Natural language, semantic analysis and interactive fiction. White Paper

Pane, J. F., Ratanamahatana, C. and Myers, B. A. (2001) Studying the language and structure in non-programmers' solutions to programming problems. Int. J. Human-Computer Studies 54, 237-264. Available online

Petre, M. and Blackwell, A.F. (2007). Children as unwitting end-user programmers. In P. Cox and J. Hosking (Eds), Proceedings of 2007 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC), pp 239-242.