Natural language, semantic analysis and interactive fiction: from practical experience to theory
<P>
This is an account of theoretical issues which came out, almost unbidden, from a practical test of the following hypothesis: that the natural language in which to write interactive fiction (IF) is natural language. In 2002 an experimental project began which would eventually build a new, higher-level layer on top of the Inform 6 system for designing IF, a system which has now been in use since 1993 (see Nelson (2001)). A new user interface aims to change the experience of writing IF, and previous Inform syntax has been replaced by natural language: specifically, a subset of English. The combination is intended to replace the existing paradigm for IF creation, essentially that of computer programming in a command-line operating system, with something far more recognisable as creative writing.
<P>
"Writing" is an ambiguous term which might equally well mean a set of markings on paper, the activity of putting words together, or the prose which results: and for the same reason we must be precise in what we mean by "programming IF", and in what we are claiming about it. First I suggest that the activity of programming IF is a form of dialogue between programmer and computer to reach a state with which both are content, and that it is strikingly like the activity of playing IF, also a continuing dialogue in which the computer rejects much of what the user tries. Secondly, the place where this activity goes on is not conceptually a single page of blank typing paper, as would be offered by a word-processor for writing ordinary prose, but is more like a blank manuscript book with facing pages which will be written in parallel text, one written by the programmer and one by the computer. Thirdly, the program which results from all this activity (the "source text") is a description of an imaginary situation which extends through time - a story, in fact. The central idea of the new Inform is to create a system in which all three of these comparisons are tautologies: that the activity is explicitly a dialogue, that the user interface looks and behaves like a book with facing pages, and that the source text reads like a narrative. The hope is that by making these affinities transparent, rather than darkly implicit, we come closer to a "natural" system for IF.
<P>
Part I below gives a self-contained description of the new user interface, as context for what follows. Part II then discusses the strengths and weaknesses of natural language as a practical tool for IF. Beneath these substantial but arguably surface changes is a conceptual shift from object-oriented to rule-oriented design, which is the subject of part III. The second half of the chapter (parts IV to VI) draws on the background research which guided the project to propound a more general argument: that the writing of IF is a form of narration; that a system for writing IF can be judged by the range of meaning it narrates; and that semantic analysis, the branch of linguistics concerned both with narrow and broad questions of meaning, is therefore of central importance to theories of IF.
<P>
Natural languages make story-tellers of us all, and are well-adapted to the description of situation and event. Semantic analysis may be able to tell us what concepts and structures within natural language give it such facility in story-telling: looking for the presence or absence of these features in programs for writing IF may provide an insight into why certain kinds of IF are written but not others. In particular, it is common ground between mathematical logic and semantic analysis that the simplest viable way to understand statements about the world is to break them down into predicates: that is, into conditions C(a, b, c, ...) which are true for some combinations of objects a, b, c, ... but not others. Predicates are to meanings, the idea goes, as atoms are to chemistry: they are the irreducible constituents of the whole. If we accept this, then it is salutary to look at what predicates typically exist within IF design systems. We find that historical systems for IF may have over-favoured unary predicates (X is open, or in logical notation open(x)) while providing only a limited range of binary predicates (X is in Y), making it unnaturally difficult to describe situations involving human agents which require more general binary predicates (X likes Y). Lastly, comparison with the literature of semantics may help to question unconscious assumptions built in to systems for IF: for instance, are containers as important as we seem to think? Do we really perceive the world in terms of objects which inherit properties from classes, or is that a conceit of computer programming? Should support for the traditionally difficult things to model - rope, sand, fire, water - be part of the core functionality of a system for IF, or are these the sort of occasional convenience which can be relegated to third-party extensions? How can we judge such questions of what matters most?
<P>
I wish to acknowledge, and those four words are woefully inadequate, the help I have received with the Inform 7 project from people who have at various stages contributed to its ideas fully as much as their practical expression: and especially Emily Short, Andrew Plotkin, Sonja Kesserich, Andrew Hunter and David Kinder. Tendentious opinions here are my own, but I could not have formed any opinion without the last eighteen months of discussion and collaborative effort, and I particularly wish to thank all those who have read and commented on drafts of this chapter.
<P>
I. A humanising interface
<P>
Early builds of Inform 7 coincided with the 20th anniversary of the Apple Macintosh user interface (1984). I had begun the project by collecting together notes into a self-styled Book of Inform, my version of the Book of Macintosh collated around 1982 by Jef Raskin (1943-2005): a mixture of the practical and impractical, and a description rather than a blueprint, and which was free to look nothing like the final product. The Macintosh team drew inspiration from the iconography and shape of road-signs, the function of the bicycle, the office environment and the industrial design of cars: the aim was to make a computer a domestic appliance as natural as, say, a kettle (see for instance the recent memoir Hertzfeld (2004)). Similarly, the Book of Inform aimed to create a radically humanising interface for the writing of interactive fiction (IF). My earlier program, Inform 6, had been a computer programmer's tool which aimed to be welcoming to creative writers: this aspired to be the other way around, and its guiding metaphor would be that of the interactive book. In 2003 I had the great good fortune to recruit Andrew Hunter, author of the best-interfaced IF interpreter for Mac OS X ("Zoom"), to the project: the reference implementation of the interface is entirely his work. David Kinder then took on the coding of the corresponding Windows interface, which was no small feat since essentially none of Andrew's code could be used there, and the entire system had to be written afresh.
<P>
To deal first with what was being abolished, the Book of Inform tried to remove the computer's filing system from the picture. Setting up a new Inform 6 project, and installing Inform 6, is a nuisance: it means creating a directory, working out commands to compile source into a story file, then to play it, run scripts through it, and so forth. This is discouraging the first time, tedious subsequently. The shortest legal Inform 6 source - the equivalent of that prototypical program, "hello world" - involves three references to filenames and is complicated enough that the books on Inform 6 suggest that newcomers copy it out blindly. By contrast, Inform 7 projects are automatically managed and look like single objects on the host computer. The shortest legal source reads: "Home is a room." Reference to other people's code - any modern system for IF must recognise the highly collaborative nature of IF design today - is made by the name of what is being included, and whom it is by. Thus the source might read, early on:
<P>
 Include the Automatic Door Rules by Emily Short.
<P>
rather as a book might be prefaced by a list of acknowledgements (and indeed Inform uses it to place just such a list in the compiled game). No filenames appear, nor any platform-specific references.
<P>
A project is a single book, not a docket of intermediate states in disparate formats and with cryptic names. But if it were one long endless stream of prose, it would quickly become disorganised (as early testing made abundantly clear). Most computer programs of any size are internally organised by being divided up into separate source files by function, but this seemed wrong for Inform because it took us back to filing systems. A partial solution came from "literate programming", Donald Knuth's scheme for interleaving code and commentary (and indeed parts of the Inform program itself use Knuth's CWEB system: Knuth and Levy (1994)). Though Knuth's writings on programming stylistics, conveniently gathered in Knuth (1992), contain little systematic thought and are essentially rooted in the debates of what is now a bygone age (structured programming: grail or poisoned chalice?), they are nevertheless well worth reading. His essential remedy was to reconcile program with book by promoting a form of program easy to typeset, so that it would always have a dual existence: a human-readable one, and a computer-executable one, both continuously kept up to date. Inform goes along with this in dividing code into paragraphs, and also (as we shall see) in indexing, but ultimately adopts the same solution that books have used since the Iliad: it divides the source text up into sections, chapters, parts, books and volumes, allowing for a hierarchy of headings and subheadings as elaborate or simple as the author prefers. There is no compulsion to use headings, but a number of incentives are offered to persuade authors into the habit: automatic contents listings, better-signposted Problem messages, and so on.
<P>
Some approaches to "interactive fiction for the non-programmer" have imitated database packages in displaying and editing projects as wallcharts, in which the various functionalities are boxes connected by lines rather as photographs of suspects are joined by threads on police noticeboards. This is seductive for object-based IF, because those boxes and lines can be related to the coarse structure of the work (map connections, most obviously). But it fragments the writing into tiny pieces. Some creative writers thrive on this - one thinks of Elizabeth Bishop hanging half-stanzas out on the washing line slung across her study - but few of us would choose to draft a novel on ten thousand Post-It notes. Fewer still would wish to edit or revise a novel written in this way, and such approaches to IF make second thoughts and bug reports tiresome to act upon.
<P>
Inform instead presents the user with an interface intended to look like an open book with facing pages. The author's work appears in full on the left-hand page, while its consequences appear on the right. This feels natural to someone reading left to right, and agrees with the conventional layout of cartoon panels. The page spread suits today's increasing use of LCD monitors in the aspect ratio 16:10, but several of Inform's testers used 4:3 monitors equally well: the gutter between the two pages slides freely left or right, closing the one up and expanding the other, so that the user can decide which should occupy the greater space. Both pages contain text which is word-wrapped in real time as the pages are resized.
<P>
Both pages contain text, rendered in a variable-pitch font with strong anti-aliasing: a font chosen for the legibility of running prose, rather than a typical programmer's text editor font, which uses a fixed pitch to preserve vertical alignments and over-stresses punctuation marks. Although syntax-colouring is offered, the result is less kaleidoscopic than in most programming environments since Inform source text has few lexical categories: there is only "quoted text", unquoted text and comment [in square brackets].
<P>
The facing pages are the forum for interplay between the writer and the computer. Inevitably this dialogue is led by the human, typing the source text on the left, and the computer's part is reactive, producing replies. In most languages programming has a code-compile-test cycle, where the compiler often rejects the code and forces the author to make corrections. This is not unlike the experience of playing through IF: think of something, try it out, make progress. Most IF critics agree that an enjoyable game requires a lively, keep-things-moving response to incorrect guesses, because guesses are more often wrong than right. But compiler programmers persist in regarding incorrect input as an aberrant circumstance in which it is inappropriate to make any judgement of the quality of the output. Compilers such as gcc also more often reject input than accept it, but do so with error messages that are nasty, brutish and short. Error messages aim at precision in characterising the exact symptom of failure, but do so in terms of the compiler's own internal data structures or methods. For instance, gcc's errors:
<P>
 (a) main.c:81: request for member 'count' in something not a structure or union (b) main.c:175: parse error at end of input
<P>
commonly arise because of routine lapses. While factually correct, both error messages imply untruths: that (a) no structure is in sight - actually both structure and member are fine, but the wrong sort of request has been used, '.' instead of '->'; and that (b) the code at the end of "main.c" is broken in some way: whereas in fact a close brace has been missed out somewhere else entirely, quite likely in a different file. Such errors describe an accident in terms of the evidence, not the proximate cause. It is arguable that only the final object code matters, which may be used by millions of people, not the passing inconvenience of the programmer: but consider what improvements to that final code might be made by a programmer whose time is not being wasted.
<P>
Indifference to the convenience of error messages is well exemplified by the current GNU standards document (Stallman, 2004), which covers the punctuation of error messages in some detail while, significantly, offering no guidance on their stylistics, other than to offer the startling recommendation that "In error checks that detect 'impossible' conditions, just abort. There is usually no point in printing any message... Whoever wants to fix the bugs will have to read the source code and run a debugger." Inform does not follow this advice: it accepts the likelihood that its own bugs will be encountered by real users and tries to deal with such contingencies as helpfully as possible, at least identifying where the problem has arisen, so that the user can try work-arounds. And in general Inform's errors do not follow the traditional Unix-command-line pattern. They are called Problems, not errors, they are not confined to one line, they are not reported by the line number on which they occur - instead, Inform talks about sections or chapters and makes generous use of quotation - and they include explanatory text which typically gives examples of correct and incorrect usage. The same basic error can result in different Problem messages according to Inform's guess at the most likely way it arose. Many of these Problem messages have been added in beta-testing, to give more rewarding responses to reasonable but incorrect things tried by the testers: a process which we found strikingly like that of finishing a work of IF, at the stage when the designer adds numerous responses to cover all the unexpected cases which turned up in testing.
<P>
The Inform "coding cycle" consists of typing or amending the source in the left-hand page, then clicking the Go button. Either the source is rejected, in which case the right-hand page responds with a report of the problems found, or it is accepted, in which case the right-hand page begins playing the resulting work of IF. If the Replay button had been clicked instead, the work would automatically play through to its last position, using the same commands. If the author finds a trivial mistake - a spelling error, say - then this can be fixed in the source and the correction verified in a matter of moments.
<P>
Leaving aside unpredictable variations based on random-number generation, interactive fiction bears comparison with turn-based games such as chess. This observation motivated an approach to testing IF modelled on the analysis of chess openings, which run together for a while but then diverge. Every Queen's Gambit begins with the same first three moves (1. d4, d5; 2. c4), but then there is a choice, as the next move decides whether we have a Queen's Gambit Accepted (dxc4) or Declined (e6). It would be impractical to study every possible sequence of play, so chess manuals instead contain tables of standard openings. Such "opening books" are essentially built by watching every grandmaster-level game reported in the chess literature and seeing where they innovate. Inform uses the same method: it watches every command sequence typed in during testing to see if this duplicates a previous test, or breaks away. The resulting structure is called the skein, because it is a braiding (or rather a gradual unbraiding) of the possible sequences of commands, which we think of as threads. The skein display allows the author not only to look through all of the games ever played through the fiction in question, but also to replay any of those games, and see what has altered. (The Replay button does this for the most recent thread in the skein.) This aims to make debugging complex works of IF a more reliable business. In large works of IF, small changes in one place often have unforeseen consequences elsewhere, and a major cause of error is the accidental inclusion of one bug while fixing another. The skein quickly grows large, but can be pruned back if the writer chooses, or can be annotated with notes such as "Test falling off cliff" which can be searched for - just as chess opening books have annotations such as "Queen's Gambit".
<P>
The final component of Inform is the index which it automatically generates for every project, after each build. At its simplest this is a navigation tool for jumping to the relevant points in the source text - an important consideration in a text the size of a novel. But it is also an aide-memoire with cross-references to the documentation. It offers a choice of viewing the index in a variety of conceptually different ways: by headings and subheadings, like a contents page; by rooms and their contents, in a map intended to follow the style of 1980s printed solution-books for IF; by scenes and their possible sequences, in a corresponding map of chronology; as a taxonomy of the kinds of thing found in the model world for the project (an idea drawn from the SmallTalk class browser of the late 1970s); and as a collation into logical order of all of the various rules. All these viewpoints are valid and Inform makes no judgement about which is pre-eminent. For example, the index of kinds shows, among other things, what objects exist for each kind. This is not the best way to see what the game contains - the map is much clearer - but is just right for an author contemplating (say) a new rule about containers, but worried that it might not always be appropriate: since the Kinds index lists all the containers existing in the world, one can see at a glance everything to which the new rule would apply.
<P>
With some user interfaces, less is more. Adobe's InDesign is a fine program but its plethora of buttons, cursors, palettes, inspectors and toolbars means that, for beginners at least, it might as well be called InDecision. Arguably graphic design requires, or at least suits, such an interface. But does IF design? Throughout the experimental period, I would always want fewer buttons and the focus kept to one window, whereas Andrew was more open-minded. Typically I would express initial scepticism, but then give in a week later, having been won round. The feature of which we are least sure is the Inspector, Inform's only subsidiary window: it gathers a collection of functions which are either needed only seldom, or which benefit from operating without the need to disturb the contents of the main window: notably the Find gadget. The Inspector began simply as an overflow for things which would not fit elsewhere, and for some months I kept it permanently closed (Inform remembers one's preferences in this sort of thing), but I now find it too useful to banish. Every user interface project needs one curmudgeon who, by doing none of the actual work, forms opinions about features without reference to how much, or how little, effort went into them. It was a great luxury that better programmers than myself allowed me to play this role.
<P>
II. The adoption of natural language
<P>
The natural language for designing interactive fiction is natural language. I believe this for four main reasons: first, it is concise and expressive when narrating spatial relationships, properties and physical activities. 
<P>
"Midsummer Day"
<P>
East of the Garden is the Gazebo. Above is the Treehouse. A billiards table is in the Gazebo. On it is a trophy cup. A starting pistol is in the cup.
<P>
The combination of what is explicit and what is implicit in this 33-word source text is sufficient to compile an IF story file with three locations, one supporter, one container and one miscellaneous item (the starting pistol).
<P>
Secondly, natural language does not obscure text by giving it multiple or misleading representations. IF is based on a dialogue of text between reader (or "player") and computer, both directions of communication prompted by textual possibilities supplied by the author. But words are just words, and it is repetitious and artificial to have to write them differently all three ways. In Inform 6 source code a typical object will be labelled with the symbol willow_pattern_vase, given the short name "willow pattern vase" and parsing data 'willow' 'pattern' 'vase'. A natural language description simply refers to "a willow pattern vase".
<P>
Similarly for states of things. If we wish a bottle to be empty, half-full or full then in most IF design systems we write code which stores (say) the number 1, 2 or 3 in some variable, then have to convert (say) 2 into the text "half-full" when printing out what is going on, and make the reverse conversion when parsing - a separation between author and player which obstructs the design process and increases the likelihood of bugs. It also results in IF code unnaturally full of numbers. Consider how the use of numbers (cloud 9, perhaps) to represent weather patterns would have obfuscated the following:
<P>
"Weathering"
<P>
A cloud pattern is a kind of value. The cloud patterns are cumulus, altocumulus, cumulonimbus, stratus, cirrus, nimbus, nimbostratus.
<P>
The Mount Pisgah Station is a room. "The rocky peak of Mt. Pisgah (altitude 872m) is graced only by an automatic weather station. The clouds, close enough almost to touch, are [a random cloud pattern]. Temperature: [a random number from 7 to 17] degrees, barometric pressure: [950 + a random number from 0 to 15] millibars."
<P>
The use of square-bracketed substitutions in text also increases clarity. In Inform 6, for instance, the above room description would have required a routine to be written, expressing unnecessary intermediate steps (such as putting a random number into a variable) and so splintering the actual text that it would have been difficult to get a sense of its literary style by looking at the source code.
<P>
Thirdly, natural language has forms of discourse which conventional programming languages lack: in particular, it has tenses. The mathematician Paul Halmos once said that one should write papers as though one were explaining matters to a friend on a walk in the woods, with no blackboard or paper to hand: to use the fewest possible symbols and notation makes for clearer exposition. So too with variables in IF, many of which are essentially ways to remember past states of play: whether something has happened or not. In natural language, we can simply say "if the black door has been open" or "the number of things on the table", for instance: avoiding the need for flag or count variables, with their names to be remembered, and the possibility of error in setting them.
<P>
Instead of examining the tapestry for the third time, say "All right, so it's a masterpiece, but is this really the time to make a detailed study?"
<P>
Inform has four tenses: the present ("is"), the present perfect ("has been"), the past ("was") and the past perfect ("had been"), allowing us to discuss the situation in comparison with history either now (in the present) or at the point where the current action began (in the past).
<P>
Finally, IF makes great use of groups of items with common properties and behaviours, often with a finite number of states, together with spatial and other relationships between them. Natural language provides determiners ("not all of", "at most three"), common nouns ("container", "door"), adjectives ("empty", "open"), prepositional phrases ("in the box") and verbs ("contains") that concisely express all of these aspects.
<P>
The following source text shows off many of the advantages of natural language. We will set up a general rule that nobody is allowed to carry excessive weight inside a container:
<P>
"Lead Cuts Paper"
<P>
A weight is a kind of value. 10kg specifies a weight. Everything has a weight. A thing usually has weight 1kg.
<P>
A container has a weight called breaking strain. The breaking strain of a container is usually 50kg. Definition: A container is bursting if the total weight of things in it is greater than its breaking strain.
<P>
A lead pig, a feather, a silver coin and a paper bag are in a room called the Metallurgy Workshop. The bag is a container with breaking strain 2kg.
<P>
Every turn when a container (called the sack) held by someone visible (called the chump) is bursting:
say "[The sack] splits and breaks under the weight! [if the player is the chump]You discard[otherwise][The chump] discards[end if] its ruined remains, looking miserably down at [the list of things in the sack] on the floor.";
now all of the things in the sack are in the location;
remove the sack from play.
<P>
Descriptions like "a container held by someone visible" narrate complex circumstances with extraordinary clarity and concision; spurious numbers and multiple representations of the same data are avoided (the breaking strain of the bag is "2kg", not 2); there is only a minimum of variables (there are two, "the sack" and "the chump") and loops are avoided by being made implicit. In "a container held by someone visible" there are two potential searches (through containers and through visible people), though in fact internally it is optimised into a single loop; "all of the things in the sack" again implies a loop, as does "the list of things in the sack", and "the total weight of things in it". Although we do have to resort to a routine to handle the case of a bursting container, it contains just three instructions, one each for the three different things that happen.
<P>

Inform does not aspire to recognise anything like the whole sweep of natural language, and in a few cases usefulness has been allowed to trump linguistic fidelity: in particular, it does not attempt to reject all un-natural language. But on the whole Inform tries to avoid eccentricity. The three self-imposed guidelines for the language are as follows:
<P>
 1. A casual reader should easily be able to guess what a sentence does, and that guess should be correct.
 2. The language should be economical, but not to the point where this compromises its intelligibility.
 3. If in doubt as to syntax, imitate books or newspapers.
<P>
Thus we use contents, index and headings in the style of printed books, and we have also already seen Inform's equivalent of "printf" - the formatted printing command - several times:
<P>
 say "You've been wandering around for [number of turns in words] turn[s] now."
<P>
The use of square brackets here is intended to mirror the journalist's rule that quoted matter in square brackets can be explanatory rather than verbatim. Escape characters are also eschewed when we want double quotation marks to indicate speech inside text which is already double-quoted: the convention is that single quotes should be used, which are automatically converted to double-quotes in printing. This follows the standard bibliographic convention on citing journal articles which contain quotation marks. Definitions of new adjectives are set out as they would be in science text-books:
<P>
 Definition: Something is invisible if the player cannot see it.
<P>
The most rewarding observation about printed books, however, was that they provide a solution to the awkward question of how to handle arrays. Conventional arrays are clearly unviable in natural language, with their indexing subscripts (we are trying to abolish spurious number variables, after all). Searching and cross-referencing of arrays only makes constructions like AppleScript's "item 23 of..." syntax painfully obstructive. We need a way to create, discuss, look up, change and cross-reference arrays - ideally multi-dimensional arrays, with functionality equivalent to Perl's associative hashes - all without explicit subscripts and loops.
<P>
Books present data in tables, typeset alongside the main text but given a title which the main text can refer to, and Inform does the same:
<P>
 Table 2 - Selected Elements 
 Element Symbol Atomic number Discovery
 "Hydrogen" "H" 1 a time
 "Iron" "Fe" 26
 "Zinc" "Zn" 30  
 "Uranium" "U" 92
<P>
Note that some columns are filled in, others left blank to be filled in during play (we shall suppose). We can look up data like so:
<P>
 the atomic number corresponding to a symbol of "Fe" in the Table of Selected Elements
<P>
(which is 26), or we can set conditions such as
<P>
 if there is an atomic number of 51 in Table 2
<P>
(no). We can sort the table in various ways, have entire blank rows, and so on: we can even loop through the table, in what is unavoidably a procedural style of coding, without the use of a loop variable. Rows are selected in turn, rather as they are in scripting languages for databases.
<P>
 repeat through the Table of Selected Elements in reverse symbol order begin;
  say "[symbol entry] is the international symbol for [element entry].";
 end repeat.
<P>

Much of what is new in Inform 7 - the emphasis on rules, type-checking, actions which pay attention to success or failure, table searching - could have been achieved by incremental improvements of Inform 6, preserving most of the existing C-like syntax. They did not require the adoption of natural language, and nor did the new user interface (some of which in fact also works with Inform 6 projects). The general reaction of experienced IF writers to early drafts of Inform 7 was a two-stage scepticism. First: was this just syntactic sugar, that is, a verbose paraphrase of the same old code? (The cynical reader will have relished the lapse into "begin; ...; end repeat" above: iteration, and table searching, are generally responsible for the least "naturally" legible Inform 7 source text.) Second: perhaps this was indeed a fast prototyping tool for setting up the map and the objects, but would it not then grind into useless inflexibility when it came to coding up innovative behaviour - in fact, would it be fun for beginners but useless to the real task at hand?
<P>
The early experience of testing Inform on large works of IF may have put these initial doubts to rest - I hope so, anyway - but that same experience brought out less immediate problems attendant on the use of natural language syntax. The first is that frequently occurring English words have difficult meanings. The copular verb to be is hard to analyse, partly because of the pre-eminent role played by equality in predicate calculus, partly because of an etymological accident in early English which conflated together meanings distinguished in most other languages. Thus the word "is" will sometimes be compiled to the computer-programming operation "=" (set equal), sometimes to "==" (test if equal), sometimes "=~" (the Perl operator for pattern-matching) and sometimes to a kind of implication not generally found in programming languages. ("If all the green trees are tall" means: if green and tree implies tall then...) Similarly, "of" is used in some eight grammatically different ways in Inform. Ambiguity is a significant hazard, not least because Inform has little contextual knowledge. If I define verbs "to break" and "to clog", and feed the following (genuine) newspaper headline into Inform:
<P>
 Heatwave bone breaks clog hospital.
<P>
then Inform will deduce the existence of two objects, the heatwave bone and the clog hospital, one of which is breaking the other.
<P>
And if words can be subtle in meaning, sentences can be worse. It is all very well for Inform to say that a particular syntax is "natural" because it has the same meaning as the English sentence it coincides with: but that supposes that English sentences have immediately clear meanings, which they do not. For instance, if we say "the President has been ill before", do we mean that the present incumbent has been ill - perhaps before taking office - or that some former chief executive has been ill? This is a problem afflicting Inform's reading of past-tense conditions such as "if the noun has been open", where "the noun" is the object typed in the player's current command - and is therefore, like "the President", a noun phrase in constant flux. I am fairly sure that the mostly correct answer to this question is that such substitutions (replacing "the President" by the name of the one in question) should be made at the "point of reference" of the tense, but in fact Inform makes such substitutions at the "point of event" of the tense instead. (See Reichenbach, 1947, for this way of thinking about tenses.) This is for the excellent implementation reason that keeping track of whether any President has been ill in office requires only continuous monitoring of a single state of health, whereas arranging things in order to be able to say whether future Presidents have ever been ill means keeping complete medical histories of everyone born in America, because we cannot predict who will some day be elected. This means that past tense conditions relating to rapidly changing variables sometimes do not do what the user expects: a bad thing. The documentation on past tenses strongly suggests that people use them with constants rather than variables: the condition "Mr Carter has been ill" requires no substitution, so there is no unfortunate clash between the point of reference and the point of event.
<P>
A further breakdown in naturalness is in some respects frivolous, but in others not. One quite often has to write sentences which, though sensible in context, end up as amusing double-entendres: "Men are usually transparent" and "A god is a kind of value" are genuine examples from Inform's beta-testing. Sentences may look natural and yet be false friends, as translators say of words in foreign languages which look close to English ones but have different meanings: actuellement is not the French for actually.
<P>
Lastly, the legibility of Inform source text depends very much on the willingness of the author to cooperate: sometimes being willing to type more text in order to choose names which make grammatical sense, for instance. Whereas I myself would spare no effort to avoid unnatural source text, Inform being my baby, other testers were more interested in getting something done than in how the source looked. However, since all of us have been chasing a moving target - Inform has changed with sometimes shocking rapidity (also sometimes shocking sluggishness) over the last year - we are perhaps not representative of the system's eventual users, who will be able to learn a more stable language.
<P>
Extensive work has been done on natural language recognition in computing, and Inform makes no claim to originality here: indeed, it could be regarded as a descendant of Winograd's program SHRDLU. (For a discussion of SHRDLU in the context of IF, see Montfort (2004).) The one practical lesson I would like to record here is that the biggest source of bugs in Inform came from my own imprecise knowledge of grammar. For instance, if we suppose that open and closed are antonyms, should "the door is not closed'' be read as equating "the door'' and "open'', or as forbidding the equation of "the door'' with "closed''? The result will be the same, but the second way is a better implementation, because it is more consistent with other verbs: the placement of "not'' after the verb is almost unique to the copular form of to be, and its apparent association with the noun which follows is only a quirk of irregular English usage. We are likely to write cleaner code if we implement "is not'' in the same way as "does not carry'': and we will not end up accidentally parsing "does not carry not''.
<P>
III. The primacy of rules over objects
<P>
The successful IF design systems to date have been object-oriented forms of C, with one important exception: Infocom's proprietory compiler ZIL, an object-oriented form of LISP. This happened partly because technology, 1975-95, obliged the source language to be efficiently compilable. (Until about 1990, an IF story file would be larger than the memory capacity of the computer which compiled it.) Those who wrote IF compilers tended to write them in C, and saw an IF-specialised form of C as an easy system to use: and when this generation of IF tools was created, around 1990-4, the actual languages were not so controversial as the idea that people should move away from "constructor kits" such as The Quill, or AGT. At any rate, the use of an object-oriented language with a strong class hierarchy was orthodox to the computer science of the day, and it neatly resembled the "hardware" of IF - the standard data structures used in story files, as exemplified by Infocom's Z-machine. In this way 1970s implementations of IF were taken to be the structural model for IF itself. I contend that, on the contrary, IF is not best described as object-oriented but as rule-oriented.
<P>
I concede that bundling properties together into object and class definitions, with inheritance from classes to instances, works very well, and will later suggest semantic reasons why this might be expected to be so. My objection is rather to the doctrine that when components of a program interact, there is a clear server-client paradigm; that one component exists to serve the needs of another. The contents of a work of interactive fiction are typically not in such relationships. If facts concerning a tortoise must all be in one place, facts concerning an arrow all in another, how are the two to meet? It seems unnatural to have a tortoise-arrow protocol, establishing mutual obligations. Neither exists to serve the other. The tortoise also eats lettuce, meanders about garden locations and hibernates. The arrow also knocks a flower-pot off a wall. By the same token, the world of a large work of interactive fiction is a world of unintended consequences. New and hitherto unplanned relationships between components of the "program" are added in beta-testing, something which the programmers of, say, a spreadsheet would not expect to happen.
<P>
A second objection is that object-oriented code for IF divides into two quite different blocks of material: (1) the objects and classes, with their properties and specific behaviours, containing the materials for the game; and (2) the mass of usually procedural code containing the standard mechanics of play - the "library", as Inform calls it (Infocom sometimes used the term "substrate", perhaps a better image). This disjunction between specific rules (1) and general rules (2) is problematic for both. First, the general rules are hard to change, because although the language is rich in flexible ways to modify specific facts (object properties), only the crudest mechanisms exist to modify general facts (library routines). On the other hand the specific rules have the opposite problem: to change them is easy but the realistic constraints of the world model are often lost in the process, because "realism" is entirely the province of the general rules. For example: suppose a golden apple is inside a closed transparent box. General rules about impermeability forbid the taking of the apple, but here we shall allow the player access provided he is wearing a magic ring. How is this to be done? To replace the complex routines about permeability would be hard work and in any case it seems inappropriate for such a one-off circumstance to be spatchcocked into general rules. So we should write a specific rule instead, but that means attaching a property to the object of the action in question: the apple. In Inform 6,
<P>
   before [;
       Take: if (apple in box && ring has worn) {
           move apple to player;
           "Your hand passes through the glass to grasp the golden apple.";
       }
   ],
<P>
This is also unsatisfactory. Whether we regard it as behaviour of the box, or of the magic ring, it is certainly not a behaviour of the apple. What if the player tries to put the apple back again, or to put something else inside? Or pushes the apple instead of taking it? What if the player is only allowed to carry four items, and is already fully laden? What if the transparent box is inside a locked cage to which the player has no means of entry?
<P>
It appears, then, that the only solution is to rewrite the general rules to include yet another hook on which customised code can be hung. The accumulation of such hooks makes IF design systems steadily more complex. Even so, in a correspondence which entirely changed my thinking on this, Andrew Plotkin observed to me that: "I'm tired of not being able to override some behavior, because there's no hook there. I want the world to be made of hooks."
<P>
Making the world of hooks is essentially a rule-based approach to IF. Instead of having large slabs of procedural code to implement general rules of realism, we break these down into the smallest possible pieces. For instance, Inform uses a rulebook called "reaching inside" whose constituent rules are as follows:
<P>
 the can't reach inside rooms rule
 the can't reach inside closed containers rule
 the can't take people's possessions rule
 the can't take component parts rule
<P>
(Natural language allows these rules to have descriptive names, and Inform's index ensures that the author need not memorise them.) At run-time, an IF compiled by Inform works through rulebooks like this to perform essentially every task. Rulebooks are entirely modifiable: they are ring-binders rather than hardbacks, and we can detach or insert rules, rearrange them or waive them in particular circumstances just as we please. Special "procedural rules" are almost omnipotent, in the same way that points of order are always called in debates:
 
 Procedural rule when the ring is worn: ignore the can't reach inside closed containers rule.
<P>
Every rule has its own scope of applicability. Some rules apply to everything, others to single items only, but many lie in between, or apply only in certain times or places. There is no longer a black and white distinction between "general" and "specific". The single most important feature of Inform is that rules are by default sorted in order of logical applicability - more specific rules take priority over more general ones - not in order of their appearance in the source code. This has two profound consequences: that the author can arrange the source in whatever way seems most helpful, for instance keeping everything relevant to particular events or scenes together; and that four or five different sets of rules, by different authors, can peaceably coexist in the same work of IF, even though they all modify the same original definitions.
<P>
A system of gradations of rules has two prerequisites. First, the compiler needs a solid understanding of types: in particular, a way to judge whether one category ("an open container") is a special case of another ("a container"). Secondly, the author needs a flexible way to describe the circumstances in which rules are to apply. Both considerations mesh well with the use of natural language: to make sense of the ambiguities of English, a strong typing system is needed anyway; and natural language is good at describing circumstances ("in the presence of Mrs Dalloway") and categories ("a woman in a lighted room").
<P>
IV. Semantic analysis
<P>
It seems to me that the most profound difficulties in natural language recognition lie not in computing, where somewhat complacent textbooks exist to demonstrate standard algorithms (for instance, Allen (1995)), but in the field of semantics. Definitions of semantic analysis vary: some, such as Ray Jackendoff, stop little short of defining it as the theory of human thinking, but a more measured answer given by Davis and Gillon (2004) is that semantics is concerned with two basic questions:
<P>
What values are to be associated with the basic expressions of a language? How does the meaning of the simpler expressions contribute to the meaning of the complex expressions the simpler ones make up?
<P>
The source text for an interactive fiction is, however, more directly referential than most texts. Here we can refute Dr Johnson's remark that words are the daughters of men, but things are the sons of God; or Fenollosa's observation that there are, in reality, no nouns in the universe. The universe of an IF contains nothing but nouns, and the word "stone" is a stone. More particularly, an IF compiler such as Inform may work by forming a model out of its source text, but it does not have to embed that into some greater model of an "outside world". It has the further luxury of reading text guaranteed to be truthful, literal and addressed directly to itself. Even so, most of the hard issues in semantics seem to arise in at least a toy form. For instance, Inform reads sentences quite similar to the notorious "donkey anaphora" example
<P>
 If Pedro owns a donkey he beats it.
<P>
in which the rules governing "it" have been construed in an astonishing variety of ways by linguists, none wholly convincing. Does "it" substitute for a specific thing (Chiquita, Pedro's hypothetical donkey), making it a deictic pronoun, or for a universal ("every donkey such that..."), making it a bound pronoun? Or is our thought process not analogous to putting a value into a variable at all? (Since this question was first raised by Geach in 1962, the literature of semantics has been routinely cruel to donkeys in the most callously offhand fashion. If they had a clubhouse, the motto over the door would be "Every farmer who owns a donkey beats it.'' But before you dismiss the anaphoric pronoun problem as trivial, try to explain why you didn't read "they'' in the last sentence as referring to the donkeys, even though it is the only plural noun phrase in this parenthesis.)
<P>
Semantic analysis falls into two strands. Some linguists regard sentences as logical propositions, while others regard them as repositories of shared concepts, unspoken ideas and sense-perceptions: see Goddard (1998) for a fascinating account of, for instance, colours and emotions as expressed in different world languages, and for summaries of a number of provocative views on how meaning may be composed. Particularly striking is the work of Jackendoff on conceptual categories which may be atomic meanings: Space, Situation, Event, Thing and so on, each suggestively similar to basic data types in Inform ("room", "rule", "action", "thing" and so on). He uses the analogy of 18th-century chemists dimly glimpsing a Periodic Table of the elements: but others prefer a comparison with the Linnaean botanists indefatigably sorting plants into species, families and so forth, until they in some sense discover a hierarchy of meaning. Either way, writers on semantics often seem to regard their field as being in its infancy, which is sobering when we consider that the first analytic grammar was written in cuneiform by a Babylonian.
<P>
There is no space here for a detailed discussion, nor should I pretend expertise in the field, but perhaps three further case studies relevant to Inform may serve to support my general contention that semantic analysis is of central relevance to a theory of interactive fiction.
<P>
(a) Does IF overstress hierarchies of containment? Inform, in common with all traditional systems for IF, has spatial ideas hard-wired into it: in particular the use of a tree structure rather than a "flat" map to model the location of things. It would be disquieting to think that we do this simply because it is easy to implement tree structures on computers and that barriers make cheap puzzles. I therefore draw comfort from the number of linguists who also regard container as a central idea: that it is, for instance, an "image schema" by which we metaphorically extend our bodily ideas of inside and out onto the world around us. The body being a container of great importance to us, we correspondingly picture the spatial world around us in terms of containment even when it is seldom so clear-cut. Why do we say that we are "in bed", for instance, when we seem to mean that we are on top of something and are more than half covered by a blanket, and when we would probably say "no" if a child asked us whether the blanket is part of the bed? Similarly, if we are asked "Where are the teaspoons?" we are less likely to answer "In the kitchen" if they are not in plain view. If A is "in" B which is "in" C, we are reluctant to deduce that A is "in" C. (For this reason, "in" is not a transitive relation in Inform.) On the whole I think the literature of semantics offers some evidence that IF's hallowed use of an object tree is genuinely natural.
<P>
(b) Do objects really have classes, and if so, are they immutable? In Inform it is a foundational principle that every thing has a "kind", and that kinds give rise to more specialised kinds. Inform gives preferential treatment to some properties (being a container) as compared with others (being open) - which sometimes leads to designers finding themselves stripping away all the behaviours of the kind of something, but being unable to actually change the kind, an unedifying spectacle. Is a container which cannot contain still a container? Perhaps not. But here, again, I suggest that Inform's "kinds" cohere well with forms of conceptual analysis proposed by Anna Wierzbicka in the 1980s. For instance, it is posited that the meaning of "bird" is that it is a "kind of creature" with a collection of what might be called default expectations, none certainties:
<P>
 people say things like this about creatures of this kind:
  they have feathers
  they lay eggs
  they can fly
<P>
The suggestion is that any of these properties can be overridden in particular cases without necessarily stopping the creature from being a "bird": thus, "flightless bird" is not a contradiction in terms, but is a "kind of bird" about which people say that "they cannot fly". This seems to me interestingly similar to the way rules are made about kinds in Inform, only to be contradicted by rules about specific instances of those kinds.
<P>
Kinds are nevertheless problematic. A substantial change between Inform 6 and Inform 7 is that the new system is single-inheritance, that is, things can have only one kind. The corresponding question in linguistics would be whether, say, "a statue of Edward VII" belongs in any convincing way to a single kind. Is it a bronze pillar which happens, as a minor detail, to resemble a man; is it a man without animation; or does it belong in some sort of overlap of the outer fringes of "pillar" and "man"? Arguably natural-language meanings are neither singly nor multiply inherited from kinds, but are instead partially inherited ("a bronze pillar with some of the aspects of being a man" might define the statue reasonably well). This seems to me an exceptionally difficult question, and the practical upshot is that Inform requires each thing to have a single kind. As a result it is chary of defining too many built-in kinds: only around a dozen meanings are considered fundamental in this way.
<P>
(c) Does it matter that most IF systems are good at modelling objects such as chairs or rocks, but bad at modelling substances such as water? Since Jesperson (1909) linguists have divided nouns into "count nouns" (chair or rock) and "mass nouns" (water or dough), and it is apparent that these two categories of noun have different semantics: two oranges, some bread, but not two breads, some orange. Enquiries into the meanings of mass nouns involve the meaning of "is a part of": one would probably not say that the left hand side of a loaf of bread "is a part of" the loaf, and certainly Inform's implementation of parts makes sense for count nouns but not mass nouns. If we ask what mass nouns such as rope, sand, fire and water have in common, indeed what makes them so troublesome for designers of IF, perhaps it is the problem that "part of" the thing is in one state, part in another.
<P>
One approach is to reduce the mass to individually counted atoms: say, to regard shingle as a pile of a hundred pebbles, or to regard rope as a chain of segments, or water as a collection of scattered puddles. This is sometimes manageable (ropes are often implemented as a chain of just two segments - the two ends) but can be inefficient and impractical at run-time when the number of atoms grows large. Most systems for liquids give up when they are divided too far. Another approach is provided by Inform's existing "backdrop" kind, which - for a multiply-present thing like, say, the moon or grass, found in many locations at once - is already a primitive sort of mass noun: this works nicely but only with the huge assumption that the substance is immobile and is present either once in any given location or not at all. As a result, it is indivisible, and one cannot pick the grass. A further issue is that, whatever method is used, mass nouns impose formidable problems to the run-time parser, which must allow the player to refer to one part of something as distinct from another.
<P>
It might therefore be said that these difficult things should be left to ad-hoc implementations by the programmer, and that no general provision should be made for them. But the importance of mass nouns in semantics suggests that they are important in conceptual pictures of the world. This argues, first, that Inform ought to provide natural ways to deal with them; and second, that the semantics of mass nouns may tell us what these natural ways are. At the moment I incline to the "single multiply-present object" strategy, rather than the "break up into atoms" strategy, since it seems more linguistically natural - all of the properties of a given puddle except for its location are, in fact, properties of water. It is also interesting to note Jackendoff's suggestion that count nouns are to mass nouns as areas are to places, or as processes are to events. Inform's index of scenes is indeed meant to be a "map of time", and is presented alongside the map of rooms laid out in space: Inform tries to treat time as like space and vice versa if possible, since natural language seems to do this, too. Inform's implementations of "region" and "scene" both involve single objects with many relationships: perhaps this is further evidence for the "single multiply-present object" strategy? I hope to work further on this.
 
V. The importance of predicates
<P>
Parsing a source text such as Inform's is essentially a problem in the model theory of predicate calculus. This is a commonplace in most rigorous approaches to semantics: cf. the introduction to Davis and Gillon (2004); for the mathematical background behind it, see for example Johnstone (1987). Once again, Inform has a very easy task by comparison with most natural language parsers: for instance it needs to understand "if", which is easily reducible to mathematical logic, but not "because", which is not. The advantage of converting text to logical propositions is that these can be simplified using mechanisable rules of deduction. For instance:
<P>
 "somebody is in an adjacent room"
 i.e., Exists x : person(x)  Exists y : room(y) and adjacent(y) and in(x, y)
 i.e., Exists x : person(x) and room(parent(x)) and adjacent(parent(x))
<P>
where Inform was able to eliminate the second of the two unknowns (the room) by noticing that it depended directly on the first (the person), which it carried out by substituting y = parent(x). The simplified form of the proposition is equivalent to the original, but compiles to more efficient code. Here room is a "unary predicate", a property which either is or is not true about a single thing; whereas in is a binary predicate, whose truth depends on a pair of things. It seems to me that a good question to ask about any conceptual model of the world is: of what order are the predicates? For instance, one way to describe the historical development of particle physics would be to note that while physicists would ideally like to minimise the number of unary predicates in their descriptions of reality - electron(x), photon(x), and such - that is nothing like so earnest as their wish to reduce the number of binary predicates: the fields of gravity, electromagnetism and so on.
<P>
I suggest that an examination of the role played by predicates in IF points up failings in today's IF design systems, or to put it another way, opportunities for tomorrow's. The original Crowther and Woods program essentially only had unary predicates: though there was a kludge to implement the famous bird-in-the-cage puzzle, the game had a limited grasp of spatial relationships. It relied on what we might call a unary predicate carried(x) rather than having any general notion of in(x, y). Only the player could carry things. This failing was remedied from the very first, MIT lab-written implementations of Zork, bringing in the containment tree we use today, or from our point of view the first binary predicate: in(x, y). At some point early in the 1980s history of Infocom, a second binary predicate on(x, y) was added: something could be "on" a table, and as a result respond to different actions from something "in" a box. For reasons I have argued above, it is perhaps natural that these binary predicates were chosen first, but there are surely others in the world: yet design systems such as Inform 6 make no particular provision for them (except for what might be called part-of(x, y), and that is confusingly implemented). Moreover, binary predicates which ought to exist in Inform 6 do not, because they are wrongly implemented as unary ones. Just as we might regard carried(x) as being in(x, player), and say that the trouble with the Crowther and Woods program was that it allowed in(x, y) only for one privileged object y, so Inform 6's unary predicate worn(x) is really an inadequate implementation of what ought to be a binary predicate worn-by(x, y). The result is a world model for IF which fails to distinguish between clothing and possessions for everybody except the player-character. More generally, the reduction of a binary predicate b(x, y) to a unary one u(x) which implicitly takes y to be the player-character - as with carried and worn - encourages a style of IF heavily centred on the protagonist.
<P>
A second limitation is that contemporary systems for IF allow the free creation of new unary predicates (attributes, as Inform 6 calls them: boolean properties, some would say): valuable(x), say, or large(x), just as we like. Most designers of IF would regard this as an essential tool. But there is little or no built-in support for the creation of new binary predicates. This is no great problem with inanimate objects, because they interdepend so little. It becomes a more serious restriction when dealing with objects which have internal states relating to other objects: in fact, to objects which have what we might call knowledge of the world around them: which is to say, to people. People have internal states very much based on other objects and people in the world. The things they recognise, the places they have been, the people they know. Throughout the first year of the Inform 7 project, I kept feeling that we should add some convenient way to implement people having memories, or knowledge: I now believe that this is a special case of a more general need to be able to create binary predicates.
<P>
Inform calls these "relations", and allows us to teach it new verbs which express them. This is a late addition to the system and it is too soon to say how it will play out, but early testing of relations does lend a powerful feeling of being on the track of something: indeed, it already seems impossible to imagine Inform without them. For instance:
<P>
 Elizabeth loves Mr Darcy. Darcy is suspicious of Mr Wickham.
<P>
Which may be syntactic sugar: but I for one would not like to live in a world without sugar. As a final note in justification of higher-order predicates, I observe that IF has had a ternary predicate right from the outset: map-connection(d, x, y), which asserts that a route exists in direction d between rooms x and y. (The failure to store this in a data structure at run-time which fully recognises its ternary status has sometimes made it quite awkward to create new directions in IF design systems: Inform among them, at present.) Inform also has the further ternary predicate same-property-value-as(x, p, y), used in the comprehension of descriptions like "people the same age as Henry".
<P>
VI. Model theory and discourse representation
<P>
Model theory may be summarised as follows. Suppose we have a collection of statements whose individual meanings we can grasp, but which may or may not affect or even contradict each other. We aim to test the compatibility of the statements, and also to find the simplest meaning which can be given to the whole, by constructing the smallest possible model for them: that is, the smallest configuration we can make in such a way that the text can be seen to be true of it. If no such model could possibly exist, then the text is nonsensical; but if it can, then the text is meaningful. This describes what Inform does quite well: the output is exactly a model of the assertions in the source. For example, given the source text:
<P>
 The red box is on the table. In the box is a coin.
<P>
In model-theoretic terms, Inform must now construct a universe set U and an interpretation function v, together with a choice
of which predicates on(x, y) and in(x, y) will hold, in such a way that the two sentences above are both evaluated as truthful for this interpretation. This mathematical description gives us a more precise idea of the principle airily called "Occam's razor" in the Inform documentation: we aim to minimise first the size of U and then the number of pairs (x, y) ? U   U such
that on(x, y) or in(x, y) hold.
<P>
Inform expresses its output as a story file, but if it were put in these mathematical terms (and its internal data structures do indeed have this shape) the above sentences would produce the following model:
<P>
 U = {O1, O2, O3}
 v(the red box) = v(the box) = O1; v(the table) = O2; v(a coin) = O3
 on(O1, O2), in(O3, O1)
<P>
(Here O1, O2 and O3 are three different objects.) How is this done? On the face of it, the problem is circular: we need v to make sense of the text, yet it is the text itself which defines v. Moreover, the interpretation function v is in no way an exact correspondence between textual descriptions and members of U: in the above example, two different descriptions both map to O1. (A valid model does exist where "the red box" and "the box" are taken to refer to different objects, but that fails Occam's razor, because it makes a universe set U which is larger than necessary.) Moreover v cannot be a simple look-up table or dictionary, because in a universe containing both a beech tree and an oak tree, v(tree) would have different meanings at different points in the source text: so it depends on context. In fact, though, the problem of building v and U is fairly easy, by observing clues such as articles and looking for names seen before. We work incrementally, first finding a model for sentence 1, then extending it to a model for sentences 1 and 2, and so on. There is no look-ahead to future sentences.
<P>
The next stage reduces - or it might be said expands - each sentence into what, in a rudimentary way, is a discourse representation in the sense of Hans Kamp (1981). The essential point is that the sentence contains both explicit and implicit meanings, so it is inadequate simply to replace the sentence by its mathematical analogue. From each sentence S, a set of "inferences" is extracted which semantically entail it, that is, such that a human reader will agree that S is a true statement about any model in which the inferences all hold. For instance, Inform reduces "In the box is a coin" to the discourse representation
<P>
 in(O3, O1), contains-things(O1), Not(room(O3))
<P>
That last inference, "it is not true that O3 (the coin) is a room", is typical of the unspoken assumptions in English which Inform stores in discourse representations.
<P>
Unfortunately, these are not typical sentences. What are we to do with "A door is always open."? One answer would be to store this as
<P>
 For all x   door(x) ? open(x)
<P>
but, especially in the initial model-building stage of Inform, we want to avoid quantifiers like "for all" if we possibly can. (That way lies reasoning, which is difficult.) We get around this by treating the unary predicates door and open as being different in character. For instance, the following text:
<P>
 The portcullis is a door. The portcullis is closed.
<P>
is not, as might be expected, represented as door(O4), Not(open(O4)). This is because Inform divides unary predicates into two sorts: being a door is the "kind" of the portcullis, an immutable and basic characterisation, certainly true or certainly false; while being closed is a mere "property", which we regard as less important, as something which might change in play later, and as something subordinated to kinds in any case. (A door can typically be closed but an animal cannot.) Inform therefore constructs a universe set which is a disjoint union of a set of objects O and a set of kinds K, with a kind function k which specifies the kind of something:
<P>
 U = O ? K,   k: U ? K.
<P>
For instance, if v(a door) = K5 then our examples so far have the model O = {O1, O2, O3, O4}, K = {K5} and the discourse representation of "A door is always open" becomes simply open(K5). This means that the inconsistency of
<P>
 A door is always open. The portcullis is a door. The portcullis is closed.
<P>
can be detected without formal reasoning. By a simple substitution we accumulate the facts about the portcullis as being open(O4), Not(open(O4)), which is easily picked up as a contradiction. These methods enable us to ensure the continuing consistency of our model world, or else to report the proper errors.
<P>
It might be objected that a few propositions are inescapably universal: for instance,
<P>
 For all x,y  in(x, y) ? Not(on(x, y))
<P>
If we want never to store universals, what shall we do with this? In principle we could handle it by extending our discourse representation for "In the box is a coin" from in(O3, O1) to in(O3, O1), Not(on(O3, O1)) but it is inefficient to keep generating these extra inferences. Instead, Inform has explicit code to check that relations behave sensibly, and when it looks through the "knowledge list" about an object in the model it looks for a few more subtle problems than the blatant contradiction in the example of the portcullis above. But this is essentially an implementation issue.
<P>
This is not a completed system. At time of writing, recent work has introduced Mostowski's generalized cardinality quantifiers (Most, At-Least-3, etc.) to supplement Exists and For all, along the lines suggested by Barwise and Cooper (1981), but the rules governing those quantifiers are still only the standard ones for predicate calculus. If we have "For all x, such-and-such" as one sentence, then the next sentence is not able to refer to the same x, because the x is bound to the limited scope of the "For all", which we have left behind. That makes it difficult to accommodate text like "Every man has a weakness. It need only be found out." It may be that the best solution is to relax the rules on the binding of variables by quantifiers, which is essentially Kamp's solution to the problem of pronouns, but I wonder if it isn't better either to (a) disallow the use of pronouns except in limited circumstances (the current solution), or (b) use an ad-hoc system for pronouns which does not try to accommodate them into the predicate calculus. Years of kicking the Inform parser this way and that, in its implementation of pronouns, has made me more sceptical than most philosophers of language seem to be about the "principle of compositionality", that the meaning of a whole discourse is a function of the meanings of its constituent parts. Maybe the mind also handles pronouns with a poorly implemented lookup table, quite separate from its parsing of the rest of sentences: who knows.
<P>
One last lesson learned. A detail omitted above is that Inform records the predicates in a discourse representation with a degree of certainty attached - impossible, unlikely, likely or certain. (There is actually a fifth state, "don't know", but there is no point recording what we don't know in the discourse representation.) Inform uses these certainty levels mostly to handle adverbs like "usually", but also in reading lines like:
<P>
 East of the Grove is the Temple.
<P>
whose discourse representation includes certain: map-connection(east, Grove, Temple) and likely: map-connection(west, Temple, Grove). The merely likely nature of the latter predicate means that no contradiction will be generated if we later find that certain: map-connection(west, Temple, Sanctum), because only a clash of certainties is reported as a contradiction. To my surprise this turned out to be both adequate and easy to implement, adding almost nothing to the complexity of the whole. It turned out that simplistic methods were perfectly good and that no formal system of fuzzy logic was required.
<P>
VII. Conclusion
<P>
Whether Inform 7 will be found useful, or whether it will join the zoo of improbable and neglected design systems through the ages which forms the most melancholy part of the IF-archive, others will tell. At time of writing (March 2005), its user base can be counted on the number of fingers I type with, which I may say is fewer than ten: the two most substantial works of IF written in Inform 7 run to about 60,000 words each, so the total quantity of prose passed through it is still no more than might be found in a single novel. But regardless of how Inform 7 is ultimately received, I hope to have demonstrated in this chapter that the practical experience of recasting IF into natural language has been fruitful in terms of raising theoretical issues. Theories of semantics can help us by identifying what is important in conceptual pictures of the world, and therefore in stories, and therefore in IF. Lastly, if there is ever to be a theory of design systems for IF then semantic analysis of source texts will play an important role. The source texts for IF are just that, texts, and can properly be the subject of readings in their own right.
<P>
References
<P>
Allen, James, Natural Language Understanding (Benjamin/Cummings, 1995).
<P>
Barwise, Jon, and Cooper, Robin, 'Generalized quantifiers and natural language', Linguistics and Philosophy, 4 (1981), 159-219.
<P>
Davis, Steven, and Gillon, Brendan S. (eds.), Semantics: A Reader (Oxford University Press, 2004).
<P>
Goddard, Cliff, Semantic Analysis: A Practical Introduction (Oxford University Press, 1998).
<P>
Hertzfeld, Andy, Revolution in the Valley (O'Reilly, 2004).
<P>
Jesperson, Oscar, A Modern English Grammar on Historical Principles (Allen and Unwin, 1909).
<P>
Johnstone, P. T., Notes on Logic and Set Theory (Cambridge University Press, 1987).
<P>
Kamp, Hans, 'A theory of truth and semantic representation' (1981), reprinted in Davis and Gillon (2004).
<P>
Knuth, Donald, Literate Programming (Addison-Wesley, 1992).
<P>
Knuth, Donald, and Levy, Sylvio, The CWEB System of Structured Documentation (Addison-Wesley, 1994).
<P>
Montfort, Nick, Twisty Little Passages (MIT Press, 2004).
<P>
Nelson, Graham, The Inform Designer's Manual, 4th edn. (The Interactive Fiction Library, 2001).
<P>
Reichenbach, Hans, 'The tenses of verbs' (1947), reprinted in Davis and Gillon (2004).
<P>
Stallman, Richard, GNU Coding Standards (Free Software Foundation, ongoing: October 2004 edition consulted).
<P>

Graham Nelson
St Anne's College
University of Oxford
<P>