Inform is a programming language based on natural language and especially aimed at the creation of interactive fiction. In the past, that’s been command-parser IF, a vibrant art form which will continue to surprise and delight us into the future, but it’s only one of Inform’s future use cases.

This is a talk about where the Inform project stands now, how it will develop, and what new features are coming on the near and farther horizon. As I go on, I will get more speculative, and I’ll try to make each five-minute segment of this talk more interesting than the previous one. But that means pacing myself by starting with some boring preliminaries.

This talk is not a report back on past work, but perhaps you’ll allow me a brief “Previously, on Inform…” segment up front, especially as this is my third Narrascope talk in a row.

Inform is a programming language. It has a compiler which does the sort of thing compilers do. But there are several ways in which it is unusual.

Firstly, most users experience it as an app or a web service, and their workflow is more like writing than coding. They may never use a command-line, or a build tool, or a text editor. What I’ll call the “apps” – Inform for MacOS, Windows or Linux – hide all of that. This is an explicit goal of Inform, so the apps are an important part of the project.

Secondly, Inform does not compile all the way down to assembly language. It compiles to a human-readable but low-level program which a further tool takes the rest of the way. That’s not unique (the functional programming language Haskell goes via C, for example), but Inform is unusual in supporting multiple target languages - currently two of them.

At Narrascope I, in Boston, I sketched out how a new intermediate representation inside Inform called “inter” might make this possible some day. That has all now happened.

Thirdly, in Inform, structures in the source text do not correspond well to those in the compiled code, and small often makes large. Even a short source text like “The Laboratory is a room.” generates what amounts to a simulation engine sitting on top of a miniature operating system. That’s typically about 81,000 lines of output, and the concept of the Laboratory is not easy to locate in that output. At Narrascope I, I used the word “kit” in public for the first time: a kit is a pre-compiled block of material used by Inform to put these quite complicated structures together. Kits are written in a low-level language called I6, compiled to Inter, linked with more Inter coming from the Inform source text, and then translated down to either C or I6 again. As I explained this happy scheme in Boston, at the back of the auditorium Andrew Plotkin was kind enough to mime his head being blown off. But it all now works, and Andrew’s head is still on.

A fourth way in which Inform is unusual has gone. It was closed source, but I announced at Narrascope I that I was nearly done with refactoring and rewriting, and would soon be ready to open-source the language and all its tools. At Narrascope II, online during the hardest summer of the pandemic, I then said that I was getting closer, but conspicuously gave no date. I also spoke at both Narrascopes I and II about what’s called literate programming, which I wanted the publication of Inform to make a contribution to. I won’t talk about that further today, but it remains something I care about.

The git repositories for Inform went public on 28 April 2022, Inform’s traditional birthday, and I’m grateful for the welcome it has received. The core repository is up to 806 stars now, which makes me feel very important — I mean, the American flag only has 50 — until I calibrate that by looking up Python, 47,000, Swift, 60,000, and Rust, 70,000. The last mouse-click after five years was a surreal moment, but also a huge relief. I could now be struck by lightning and my life’s work wouldn’t be lost. Well, I realise that hoarding stars, and talking about my life’s work, are both vanity. But it was quite an emotional moment.

That was three months ago. What we had then was a beta of the next proper release of Inform. People are already running these betas of version 10, on the command line, or in previews of the Windows, Linux or Mac apps, or on web services like borogove.app, or even in Docker containers or Github Actions. Here’s the new version of the Mac app, running on MacOS Monterey, in both Light Mode and Dark Mode - Dark Mode is new. As of today, this Mac beta is available at Toby Nelson’s github pages. Time was when you compiled a program and then other people ran it, but it’s now a complicated business shipping an app for a consumer operating system. Toby’s app is, I quote, “hardened, entitled, sealed, signed, provisioned, archived, imaged, notarised, and stapled” but not yet “sandboxed”. I salute Toby, and David Kinder and Philip Chimento on Windows and Linux, for coping with this world.

A new feature here is a nice Web service giving a calendar of upcoming community events, which I hope will connect users with the excellent IFTF Foundation, our hosts here at Narrascope.

So the genie is out of the bottle. We must now bring the beta period to an orderly end, and make a proper release of 10.1: we’re very nearly there, with just some Public Library tidying-up left to sort out. It’s time to have procedures for how to manage releases from here on, so here goes.

Inform is developed in public. Command-line users comfortable with git can always get the very latest state. But that potentially means endless different versions of Inform out there in the wild. To clarify this situation, all versions are numbered, and we will distinguish between “release” versions, which are ready for public use, and “unstable” versions, which are not.

“Release” versions have simple version numbers in the shape X.Y.Z. As I mentioned, we’re coming up on 10.1.0.

“Unstable” versions are commits of the software between releases. You can always get these from Github, but you probably shouldn’t. Unstable versions have much longer version numbers, containing an -alpha or -beta warning. For example,

10.2.0-beta+6V35

This would be an unstable version working towards what will eventually be 10.2.0. The +6V35 is a daily build number, which most people can ignore. Actually that’s not true. Everybody can ignore it.

Going forward, we will mostly not provide binaries of the apps for unstable versions - only for releases. Right now there are downloadable apps of the 10.1.0 be unstable versions of 10.1.0 available on all three platforms, but we’ll be taking those down as soon as there’s a proper release to provide instead.

Two minutes which will make sense only to developers who use the source control system “git”. In the core Inform repository, active development is on the “master” branch, at least for now. That will always be a version which is unstable. All releases will be made from short branches off of “master”. For example, there will soon be a branch called r10.1. This will contain as few commits as possible, ideally just one, which would be the actual release version of 10.1.0. But if there are then point updates with bug fixes, say 10.1.1, 10.1.2, and so on, those would be further commits to the r10.1 branch. Later, another short branch from master would be r10.2.

Releases will be tagged with their version numbers, so the commit representing 10.1.0 will be tagged v10.1.0. These will be presented under Releases in the usual Github way, from the column on the right-hand side of the home page. We expect to provide the app installers as associated binary files on those releases, though that won’t be the only place they are available.

As I say, all versions will have a three-layer number in the form X.Y.Z. A brief word on what this means. In a pragmatic, not quite strict way, this will be a semantic version number. For those who don’t use it, semantic versioning, or “semver”, is an Internet standard for how to assign software version numbers. See semver.org. Semver was created mainly for component parts intended to be used inside other people’s programs. (Inform extensions are like that, and now use semver.) In those situations, strict adherence to the rules is good. But for big umbrella-like systems, such as programming languages, strictly following semver tends to be unhelpful, because all that happens is that Y and Z are never used at all.

Here’s what I intend to try, and we’ll see how it goes. The three parts of the number X.Y.Z are called MAJOR, MINOR and POINT. My plan is:

• if a release withdraws any significant functionality or syntax, or significantly changes how an existing feature works, the MAJOR number must increase;

• if any functionality or syntax is added, or a not very significant change is made to an existing feature in a way which probably won’t cause anybody problems, the MINOR number must increase;

• if the only changes are bug fixes, only the POINT number increases.

The weasel word here is “significant”. For example, 10.1 withdrew several forms of the Include (- ... -) syntax: that was a MAJOR change. But the proposed increase in precision of how Inform handles real numbers, which I’ll come it, is more like a MINOR change.

So let’s talk about some changes. Most major programming languages have a formal system of numbered proposal documents, hosted on their own public repository: for example, Swift Evolution and Rust RFCs.

In England, by the way, RFC stands for Rugby Football Club, which is not completely inappropriate to how compiler developers debate things. But really these are very helpful services for users of the languages who want to see what’s coming next, or want to have their say.

We are today making a new github repository public: inform-evolution.

“inform-evolution” holds similarly numbered proposal documents. At this stage, “proposals” are likely to be originated by the core Inform team, and will serve as both specifications of what we intend to implement, and as requests for community comment. Details may change and a few proposals may be withdrawn in favour of better approaches, but it’s reasonable to assume that when a potential change reaches proposal status then something like it will happen.

From now on, any language change large enough to cause a MAJOR or MINOR version number bump to Inform should result from a specific IE proposal. Proposal numbers will also be useful in marking commits. For example, a commit title like:

(IE-1234) Refactored kinds ready for meta-hyper-kind support

would be a signal that this is to do with implementing IE-1234.

For now, IE exists really to help the people already working on Inform to do some thinking in public. When Inform has been open-source for longer, we will need some process for users outside the core team to create IE proposals, and then to have a reviewing committee as gatekeepers. What I think IE will never be is a vague “wouldn’t it be nice to have something like this” channel - IF forum discussions are better for that.

“inform-evolution” currently has 10 proposal documents, IE-0001 to IE-0010, and those already give a good picture of what’s coming next. I’m going to take a tour, though not in numerical order. I’ll start by running quickly through a miscellany of small features, and then come to a middle-sized one, and finish with an enormous proposal.

What do I mean by small? Well, for example, IE-0005 is a change to make Unicode character names quicker to resolve inside the compiler. This will affect hardly anyone, but because it means withdrawing the hardly-used X translates into Unicode as Y sentence from the language, our rules say there has to be an IE proposal.

IE-0008 is also a small proposal, though in the end its effects may be large. It’s called “Faster memory allocation”, and proposes a low-level change to how the Inform runtime claims and releases memory. There are no language changes at all, so this change doesn’t strictly speaking need an IE proposal. But we’re giving it one anyway because it’s a significant piece of work, and just might change memory behaviour for a few existing projects.

In the same way, IE-0007 makes no language changes but doubles the precision of arithmetic used by Inform’s real number kind. This makes Inform real numbers similar to double rather than float in the C language. In particular, it means that any Inform number value can be faithfully promoted to real number and then rounded back to number without being changed by loss of precision, which can happen now. Again, this change in principle affects the runtime behaviour of existing projects, but (a) not very much and (b) almost always for the better. But it gets a proposal number even though it does not change the language as such.

IE-0004 is an example of a purely additive proposal, that is, it adds a new feature to Inform which won’t cause any existing projects to break. This enables Inform to take advantage of an existing feature of the “blorb” packaging format in which binary data files can be packaged up with a story file. This looks innocuous enough as a proposal, but it may turn out to be a Trojan horse for how file system access to binary files might be provided in future.

Another proposal, IE-0006, also lays a little groundwork. This is really a proposed standard way to annotate Inform 6 syntax code, which is a joint proposal with the maintainers of the Inform 6 compiler, David Kinder and Andrew Plotkin. Such annotations may be used in future for better control of how kits are linked, but IE-0006 doesn’t go there yet: it’s just preparing the way.

Next up, there are two small proposals aiming to help power users with large Inform projects put under source control. IE-0002 is a simple convenience under which Inform automatically makes .gitignore files to make it less of a fuss to start Git repositories which hold Inform projects.

IE-0003 is a mechanism for source text to be split up into multiple text files. This is intended as a drop-in replacement for what projects like “Counterfeit Monkey” are already doing, which is to have large numbers of what are supposedly extensions, but which are not really anything of the kind. For example, CM contains:

Include Act I Among Sightseers by Counterfeit Monkey.

[Book 1 - Act I Among Sightseers]

Well, clearly “Act I Among Sightseers” is not intended as an extension to the Inform language, for use by multiple projects. It’s the text of the material under the heading “Book 1 - Act I Among Sightseers”. Under proposal IE-0003, this can just become:

Book 1 - Act I Among Sightseers (see "Act_I.i7")

which has a clearer intention, I think, and means that no bogus extension needs to be created. The file Act_I.i7 then lives in the new Source subdirectory of the project’s Materials directory.

That completes the miscellany of small, harmless, nice-to-have but not especially exciting proposals. Now for a larger one.

IE-0001 changes and greatly expands the way Inform extensions are stored, and allows them to be bundled with further resources. This is a bigger deal than it first sounds.

Since the beginning of Inform 7, an “extension” has been a single file, with a .i7x filename extension. The idea was that it would contain Inform source text providing new phrases, rules and so on for users to benefit from. Locksmith by Emily Short, for example, provided a tidy implementation of locks and keys.

After a time we found we needed extensions to be able to provide documentation and examples of usage and test cases.

Those had to be awkwardly crammed into the bottom of an extension file, because there wasn’t anywhere else. Similarly, an extension couldn’t be supplied along with associated low-level Inform 6 code, but this could be faked through heavy use of Inform’s Include (- ... -) sentence. The result is that extensions are already straining the limits of what can reasonably be crammed into one text file.

And even so, there’s no way for an extension to come with associated images, data files, sound effects, or kits, for example. Similarly, a French Language extension can’t come with Preform files of language syntax or with natural language metadata somehow built in. All of this makes it a nuisance to distribute really ambitious features with extensions. Three of the extensions supplied in the core Inform distribution need kits to make them work, I note.

IE-0001 therefore presents a comprehensive expansion of the extension format. Existing one-file extensions will work exactly as they do now, but it will be easy to migrate those to “directory format”.

Once that has been done, a whole host of optional extras can be added:

Red Fire Hydrants-v1_3
		extension_metadata.json
		Source
			Red Fire Hydrants-v1_3.i7x
		Documentation
			Documentation.txt
			Examples
				Alpha.txt
				Zulu.txt
			Images
				diagram.jpg
		Materials
			Inter
				RedFireHydrantsKit
				DefaultFireFightersKit
			Figures
				dalmatian.jpg
			Sounds
				gushing.mp3

Particularly notable here is that directory-format extensions can provide JSON-format metadata, allowing them, for example, to say that certain features in the Inform compiler should be turned on or off when the extension is used.

This set of changes is major enough that the Inform apps will need changes to accommodate it, especially in how they download extensions and install them.

To digress for a moment, IE-0001 is really part of a wider manifesto for how Inform resources are distributed. At present, only extensions are really shared among Inform users, with a sort of central registry, the Public Library, which doesn’t do a very good job at present. But it doesn’t handle versioning well, it’s selective, and people may want registries of their own.

Inform’s build manager, inbuild, should some day solve all this. It sorts out metadata and works out dependencies between Inform resources: it can say exactly what extensions and kits are needed to compile an Inform project, for example, and which versions would be needed. Work has already begun on giving inbuild a formal concept of “registry”, an Internet location - almost certainly a Github repository - holding Inform resources which inbuild could, in principle, browse and fetch from. But inbuild cannot yet fetch missing resources from the Internet.

While we will want to generalise this so that anyone can set up a registry, we probably also want a central registry - compare RubyGems for Ruby, the Node Package Manager npm registry, or the Comprehensive Perl Archive Network. The “Friends of I7” collection of extensions is already something like this, but not quite. This is all too hazy to have a numbered proposal yet, but we can see it shimmering in the distance.

That takes us to the huge proposal IE-0009, which we’re calling “Dialogue”. This may completely change how Inform is used in practice, and opens up the possibility of creating entirely different interactive experiences. The one-sentence pitch for this feature would be: Flowing conversation as easy to write as in IF languages like Ink or Twine, but the full power of Inform’s world model and natural language conditions and actions underneath always available to enhance that.

IE-0009 is intended to help authors of command-parser IF incorporate dialogue better into projects, and it is intended to help authors of non-command-parser IF to write entirely dialogue-based stories, and it is intended to help users in the commercial space to build dialogue engines into games which may not be graphical at all.

We see no contradiction in serving all three of these groups of users. We’re a big, varied, and exciting community, doing all kinds of things in all kinds of ways. Authors of the 2020s want different things than the authors of the early 2000s, and Inform exists to serve authors, not the other way around.

While IE-0009 makes enormous additions to Inform, it takes away almost nothing, so it will be a non-disruptive change for existing users. But because the change is so huge, it’s likely to be introduced in a major, not minor, release of Inform, perhaps as the lead feature of Inform 11.1.

Well, so what is Dialogue? It’s the ability to have sections of an Inform source text which look like a printed play or movie script rather than like a printed novel or short story. Dialogue was designed by Emily Short, who is one of the world’s leading narrative designers, and in particular is an expert in this conversational-modelling space. It looks simple and easy to write, but gains great flexibility from being underpinned by the full power of Inform underneath.

Section headings are nothing new in Inform, of course, but here one has been marked as containing dialogue. That means the sentences under this heading follow a quite different syntax.

Assertions, rules and tables are all forbidden, and instead we have “dialogue beats”. A satisfying scene in a story is probably going to be many beats, flowing one into another. A “beat” can be multiple lines of dialogue or narration, but with a single reason for being performed - that’s called the cue, and is written in brackets.

Note that beats can be “about” people, things or abstract ideas - indeed, we have another proposal, IE-0010, for a new kind called “concept” to be used by Inform for abstractions. So you could create a concept called “world peace”, say, and then use that as a conversational subject. But here we have a fence, which is a thing in the story.

The lines of dialogue are only performed if the people saying them are audible to the player. If the potential speaker is somewhere else, or has left the story somehow, the line won’t be spoken.

You can also add all sorts of standard Inform world model, and have dialogue depend on it. Building this out:

Note that Huck now speaks only if the fence is unpainted.

All this may look like a simple dialogue tree, but it’s much more flexible than simple examples show. This, for example:

One of the lines here is performed by “A boy other than Huckleberry”. At runtime, a speaker will be selected who is audible, a boy, and not Huckleberry. (That person might be the player.) And in general, almost everything you see in these slides can be customised with the full flexibility of Inform.

Dialogue can also be conditional on someone being available to talk to.

Huckleberry (to Tom): "I'm getting an idea."

This also makes Tom the most likely person to reply, if there’s a choice.

Conversation does not always flow on rails laid out by the author, and can also naturally pick up conversational subjects. The author could write:

Huckleberry (mentioning the fence): "See that wind-blown old fence?"

That line might end the beat, and yet not end the conversation, because it might lead to another beat:

(about the fence)

Tom: "My father hammered that ol' fence in back when we put up the barn."

A runtime system called the “director” chose that beat to be performed next because it knew that the subject of the fence was hanging in the air after Huckleberry’s previous line.

Dialogue can not only depend on the state of the world but also change it:

Huckleberry (if the fence is unpainted): "Say, that fence needs painting!"

	Tom (now the fence is painted): "Let me have that brush... All done."

And there are actions, too, which as always in Inform can be performed by any character:

Huckleberry (after taking the paintbrush): "I'm going to fix this."

If the action Huckleberry taking the paintbrush fails for some reason, the line of dialogue is not performed. And so on.

Next we come to choices. In the dialogue system, we’re offering choices in two different ways: one where there’s an explicit set of choices for the player to choose from, and one where it’s open-ended and left up to parser commands. Here’s a simple choice of just two options.

Huckleberry: "Should we go to the schoolhouse now?"

-- "No, I'd sooner build a raft!"

	Huckleberry: "Guess we do live near the Mississippi..."

-- "I s'pose."

	Narration: "Huck's face falls."

There’s a whole automatic process of not reoffering options, of making options conditional on the world state, and so on: it’s much more flexible than this example shows. Indeed, the “director”, the runtime manager for conversation, does its work through activities and rulebooks, just like other components of Inform, which makes it highly customisable.

All of this makes it possible to create sophisticated choice-based fictions with the same sort of ease as the original Inform made command-parser fictions. But you can have a command parser as well, or instead, or mix the two exactly as you would like. Here are choices presented via the command parser:

Huckleberry: "What'll we do about this fence?"

-- instead of examining the paint

	Huckleberry: "That pot came on the railroad right from Ohio."

--

	Huckleberry: "Guess we'll leave it for now."

Here, the dialogue breaks off for a turn of the story. In a command-parser game, that means giving the player the opportunity to type a command, parsing it, turning that into an action, and trying the action. What happens here is that if the player asks to examine the paint, Huckleberry cuts in and the dialogue continues.

Choices are also highly customisable and there’s much more that we could say, but the full proposal is at inform-evolution, and that finishes this tour of new features on the near horizon.

There are also hazier hopes for the future of the programming language, which haven’t reached any kind of proposal as yet. As mentioned, one is better support for the fetching and publishing of shared resources like extensions. Another is support for additional data structures, and better ways to handle namespace collisions.

The Inform tool-chain is no longer tied to interactive-fiction specific virtual machines - it can now turn interactive fiction into native C programs. You might ask, how does that help anyone? Well, they do run faster as native code, as it happens, but the real point is that they can be linked into larger, external projects much more easily.

In particular, a large commercial game build on technologies like Unity or Unreal Engine could now, in principle at least, use an Inform source text as its dialogue engine, or just to generate dynamic text needed at some point in its gameplay. We want Inform to do what it can to serve those users. There is precedent for this: Ink has plugins for both Unity and Unreal Engine.

How much progress we can make on that will depend on whether volunteers come forward who are able to build out the Unity/Unreal side of the technology needed. But here is the picture as I see it:

Unreal Engine may be the easier target, though with some limitations. Unreal is a game engine with a built-in scripting language called Blueprint. It’s possible to write games using only Blueprint scripts, so that you never compile at all - you’re just using Unreal as an interpreter. It’s hard to see how those developers could access material produced by Inform. But games on Unreal more usually do recompile the engine themselves, sometimes to extend its features, or wrap them up in some way. Since the engine is written in C++, it is relatively easy to link it with code written in C, like the output of Inform. But in order to make this a good experience for developers using Unreal, we would need somebody to write a C++ wrapper which would nicely wire up functions provided by Inform to scripting features in Blueprint.

The picture on Unity is similar, but with a complication, which is that the Unity engine is written in C#, not C++, and C# is slightly troublesome at interfacing with C code. It’s certainly possible to get around this, but we think a cleaner plan would be to add C# as a new output language from Inform. An Inform source text might then compile to a single C# class, which, again, might need some wrapper code to be conveniently accessible to Unity developers.

As I say, whether we can make progress will depend on whether people, either in the commercial space or hobbyists using these tools, are interested in giving this a try. But the API from the Inform side is already built and working, and the advice we’ve had is that the task of making plugins for these engines shouldn’t be too difficult from here.

Providing text-handling for game engines is only one way which Inform could be a component of some hybrid system. I’m going to be very brief here, but a handful of examples might suggest how many possibilities exist.

First, commercial-space games could still use Inform, even if text plays very little part in them. Inform actions could provide logic for modelling what the player can do with interactive objects in the game. Rules and rulebooks can be used to model NPCs and what they do in response to movement, or other stimuli. Inform scenes can be used as part of a storylet selection system, choosing which game scenes play out next.

More abstractly, Inform can be used to generate text. Pseudo-random text is as old as gaming — the 1984 BBC Micro game “Elite” featured pseudo-random galaxy maps with planets exporting “carnivorous arts graduates” — but the suggestive qualities of proc-gen text are now made for their own sake. Emily Short’s “Annals of Parigues” is a good example, and was partly written using Inform.

But this could be taken further. Proc-gen text made by Inform could be used to create training data for larger text systems, for example. Or we could imagine using Inform to create a toy world in which other AI-driven generators could be tested and trained.

Lastly in this brief section, consider the possibilities of creating Inform content — either dynamically or in advance — using GPT-3, a so-called Large Language Model. Here are a handful of little playground experiments running in OpenAI.

The davinci model is asked here to ‘describe furniture that looks like it belongs in an American living room circa 1977’. Green text is invented. It has chosen to call the TV set “A large boxy television that takes up most of the space on the table.”

Told instead that the situation is Victorian, it says the table is “made of rosewood and has a marble top”.

There are all sorts of obstacles to using GPT-3 in production games. It’s commercial, and the fees scale badly. And like all large language models, it tends to hallucinate, and may say things you really don’t want it to say. All the same, this technology is on the march. My point with these slides was just to say: in its new architecture, Inform could be connected to a lot of other stuff.

So, then, I am the author of software called Inform for creating interactive narratives. Inform is a programming language based on natural language, and it’s been widely used by writers and educators since the early 2000s. My day job is at the University of Oxford, where this is our first term without students in residence since the great plague of 1665. Instead we have held over 40,000 video meetings. You can’t fault us for conversation in a crisis.

Let me begin with more recent history – Boston, in the year 2019.

At Narrascope I last year – I’m not sure if we write that with Roman numerals, like Superbowls – I promised to complete publication of the Inform source code by “Autumn 2019”. Now, Autumn is a word with a good deal of give in it, but I think we can all agree that it is now 2020. Like programmers since the beginning of time, I underestimated what was involved.

Something else I talked about at Narrascope I was “literate programming”, a method for writing code which blurs the difference between a program as a functional thing and a program as a text for humans to read.

Many aspects of Inform have been influenced by literate programming. People have, for example, published Inform “programs” as books. Part of the appeal is to make a sort of art object out of code, and a few digital artists are doing just that.

For example, Lingdong Huang’s rather wonderful wenyan-lang language, which you program in classical Chinese. This is the Mandelbrot set as drawn by a wenyan-lang program. The writing beside the diagram is the actual code. Imagine how excited archeologists would be if they found this page in a jar in the desert somewhere.

But the original purpose of literate programming is to explain and justify a program, and to give a description of it which has real power to justify its correctness and record its design decisions. That is what I’m doing with Inform.

People are giving me every encouragement, both direct and tacit – I currently have the unusual combination on Github of having 193 followers and zero public repositories. Following me cannot be a gratifying experience for those 193 people, but it does mean something to me. I feel the presence of those watchers every time I check code in: I feel it as patient encouragement. Somebody cares.

For those followers, and even to those kind people who email to say that the responsible thing would be to publish weekly bulletins on my progress, I really am sorry to be running late. I do feel that I’ve learned a lot in the year since Narrascope I, though, which was a really important event for me. So that’s the Previously, and now I’ll start again with a proper title.

I’m going to talk about what it means to explain a program, how I am approaching that problem, and where I actually am with it.

At one level software is an affordance: a lever to pull when you want something. But at another level it’s a social event, or a gathering. Even with the most vending-machine-like tools – say, I want to unzip a zip file, I’ll use the Unix command “unzip” – there’s always a little social tide pulling at you. I look at the man page for “unzip”, and suddenly I’m part of a tradition of pioneering developers whose tools all interlock with each other. I start to recognise patterns, then I start to imitate them.

Engagement is interesting because it involves groups of people making collective choices. Persuading people to engage is a lot of what we do as teachers. Engagement is also interesting because it is a two-way process. It’s not just that people choose software to fit their needs. They also choose their needs to fit their software. Compelling software changes the way you think about what you’re doing.

So I want to talk about engagement, and I’m going to borrow from a cliché of user interface design – the idea of “progressive discovery”.

The idea is broadly that a user interface like this one, the user interface of a Boeing 747, is a bit much for beginners. Maybe the first time you sit down, there should just be the throttle and an on-off switch, and then after a few hours flaps appear, and so on. This is hard to do and it often fails. But the idea is still good, and is also used in documentation. Chapter 1 often tells white lies about how simple a program is, but by Chapter 8 the reader is ready for the truth.

A similar process applies to the way people slowly befriend their software, and make it a part of their lives. I’m going to call that “progressive engagement”, and I’ll divide it into five stages.

To be clear, when we teach students about creativity software – Twine, or Inform, for example – it’s not our job to be a sort of certification instructor. It’s not about the students turning into expert users. It’s about removing pain points, about letting them be creative. The best software is invisible but always there, like a butler in Downton Abbey. From that point of view, only the first two or three rungs on this ladder are relevant to educators. But I hope you’ll bear with me as I climb down, or up, the ladder all the same.

Each stage in my progression comes with its own materials, which facilitate the process of engagement.

My first stage is discovery: so, how do people decide, for example, what language to use when they need to write a program? How do people discover software? Sometimes employers or colleges choose for them; sometimes they join an existing community – they ask, “what are the cool kids using?”; sometimes they follow popularity as a proxy for what is likely to be well maintained. But there is also a role to be played by advocacy.

Advocacy can be anything from quirky blog posts or podcasts to recommendations in person. In its purest form, advocacy comes down to what movie people call the elevator pitch. How do you sum up software in a couple of sentences?

Here are the straplines on home pages for some recent languages:

Rust: “A language empowering everyone to build reliable and efficient software.”

Go: “Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.”

C#: “C# (pronounced “See Sharp”) is a modern, object-oriented, and type-safe programming language.”

Swift: “Swift is a general-purpose programming language built using a modern approach to safety, performance, and software design patterns.”

There are shades of meaning here but these four pitches are basically the same, because these languages are like four actors all auditioning for the same part. Their advocacy can’t be very effective because these languages are not, in the end, very different from each other.

Advocacy comes into its own when languages are more unusual. Here are some more:

Python: “Python is a programming language that lets you work quickly and integrate systems more effectively.”

Haskell: “An advanced, purely functional programming language.”

Common Lisp: “Common Lisp, the programmable programming language.”

AppleScript: “AppleScript is a scripting language created by Apple. It allows users to directly control scriptable Macintosh applications, as well as parts of macOS itself.”

CSS: “CSS is a language that describes the style of an HTML document. CSS describes how HTML elements should be displayed.”

On this slide, languages are competing on different axes. It’s no longer “pick me, I’m better”; it’s “pick me, I’m a whole new thing”. This is where advocacy counts most.

If you will forgive a digression at this point, I think there’s some comparison between how creative people choose software and how scientists choose theories.

In both cases you have practitioners choosing between conceptual tools, which are often about equally able to get practical results. This textbook was printed in 1550. It puts the centre of the Earth at the centre of the Universe, and it works just fine for calculating where the planets are in the night sky. Two generations later, people were putting the Sun at the centre, and doing their calculations differently, but getting about the same results to the same accuracy. In a similar way, two generations have seen COBOL and FORTRAN replaced by C++ and Javascript. Not many programmers moved from one to the other. Instead, new people entering the field were taught differently.

How does that teaching work? How do people advocate for one theory being better than another? Here is a classic answer given by Thomas Kuhn in 1977. A good theory, he said, had five properties:

• accuracy in solving problems

• consistency with both itself and other theories

• broadness of scope (“consequences should extend far beyond the particular observations… it was initially designed for”)

• simplicity (“bringing order”)

• fruitfulness

Those are all good criteria on which to judge programming languages, too. So perhaps the home page for the perfect new programming language would have a strapline like this:

Kuhn. A language that’s accurate, consistent, broad in scope, simple and fruitful.

In practice, many languages are intentionally aiming at three or four of these while sacrificing the others. In Inform’s case, we are throwing out “broad in scope”.

Inform is not intended for much other than narrative interaction. But it certainly wants to be accurate, consistent, simple and fruitful. It can be debated whether or not it’s any of those things, but I hope that’s what advocacy for Inform would say.

So much for the elevator pitch. How do we get people on board? We invite people to start using the tool: go on, we say, have a go, we say, give it a try, we say, we know you’ve already tried enough software for a lifetime, but this one won’t be any trouble. Just a leetle, waffer-thin mint.

Teachers and workshop leaders are crucial here, and I’m conscious that many people listening now know more about this than I do. Still, I’ll try to ask: what should we do with our students when we’re getting them started? I suggest two principles.

My first is: go where the people are. Unless software is very simple, it will always have a whole landscape of possible use cases, but somewhere in the middle of that landscape is a sort of capital city. We should take our students there, not to intriguing outlying communities.

For Inform, that probably means a short and sweet narrative, with a little state involved – enough that some relationship between things or people will change during the experience, even if it’s as simple as the “X is carrying Y” relation. A visit to a place, a meeting with a person, a historical moment.

Many programming tutorials start with “Hello World”. I have to say that I find Hello World a little bit pernicious. Every language textbook since Kernighan and Ritchie in 1978 has begun with this, but there’s no need to keep on perpetuating the style or expectations of old Unix world today. I feel rather the same about the interactive fiction equivalent, a story called “Cloak of Darkness”, which imposes a very 1980s idea of what IF can be. Doing “Cloak of Darkness” in Inform 7 is a retro sort of exercise, like learning the piano by playing Nintendo-style music on a monophonic synthesiser. It feels off-centre.

My second principle is that when teaching any tool, we have to inhabit its world, and go along with its metaphors. Photoshop can readily be used to edit 8 by 8 bitmaps but the writers designed it for photos. They used metaphors like cropping and brushing, using a sponge, using a filter. So teachers should probably start by getting students to clean up a photo. The metaphors used by software are its organising ideas, and therefore its source of simplicity.

This is certainly true of programming languages, which usually claim to have simplicity by trying to fix one big idea in our minds. Often it’s the “everything is an X” idea. Everything is a list! Everything is an object! Everything is a protocol! Of course, users coming on from other languages often don’t see it that way, and want to imitate what they’re used to – a big problem for Swift, for example, which didn’t articulate its message about protocols very well at first. So it’s important for early teaching to stress the big ideas.

For Inform, there are two big ideas: relations and rules. Of course they are always present, in that declarative sentences like “A ball is on the table” are establishing relationships, and paragraphs like “After taking the ball, say “It’s heavier than you thought.”” are rules. But it’s good to give students the abstract idea of relations and rules early, and encourage them to make new verbs and relationships of their own, I think.

As for metaphors, our main metaphor is that writing Inform is like writing a book. For example, the Table data structure looks like something from a school textbook.

This next and middle stage of engagement is where a new user is invested enough to really get to grips with it: perhaps even to read the manual. This stage is the one which Emily Short and I thought most about in the early 2000s when Inform 7 was starting, and we ended up at what was then an unusual approach, but looks a little more normal today.

As you may know, we have two intertwined books of documentation, a manual which attempts to progressively reveal the language, and a recipe book of about 450 worked examples. The examples are Inform’s alternative to having a large library of standard code supplied with it: if you want to find out how to write a story all about gas diffusion, or magnetism, or encyclopaedia sets, or an election, it’s all there somewhere.

Much of this documentation has changed little in the 2010s, and it may be getting a little tired: I’d be interested to hear from educators on this. One loose end at present is that the Inform documentation is not actually available as a printed book. I increasingly think we should get to that, if only to be sure that there’s something up to date at Amazon.com. But the heroic days of the printed manual for software — those Addison-Wesley books of the 80s, or O’Reilly books of the 90s — are, I think, mostly behind us.

The next stage of engagement is where people become sufficiently committed to software that they want to extend it, and not necessarily for their own use.

In order for this stage to be possible, the software has to provide features which enable it. This is where programs tend to grow SDKs, or plugin architectures, or provide app stores — that sort of thing.

And Inform does provide some of this — it has a system of extensions.

Anyone can write an extension, and for the most part, it’s just like any other Inform writing, so there aren’t new skills to learn. That’s the up side.

The down side is that throughout the history of the Inform project we’ve wrestled with how best to make extensions discoverable and manageable, but we have only partially succeeded. We’ve tried having a central repository, and we’ve tried not having one.

There are also significant issues with how users are supposed to cope with dependencies. Large projects often use 20 or more extensions, but authors all too easily get into versioning hell, and it becomes hard for different authors to exchange projects because they don’t carry extensions along with them.

To that end, the new version of Inform includes a build manager called “inbuild”. Here it is doing some tricks at the command line; the details don’t matter at all, so don’t worry if this slide is illegible over Zoom. Inbuild can identify sort of resource a file is, what version it has, and what else it needs in order to work properly. Inbuild can also archive projects, taking snapshot copies of just those extensions a project needs. Given that, you can reliably email a project to somebody else and have it work at their end.

This is typical of the new features being added to Inform in this round, which are about having a better infrastructure. For example, Inform now creates suitable gitignore files to make it easier to put projects under source control. In 2005, the idea that programming newbies might use source control was just too utopian: but today it’s far more common for students to use Github. What remains the case is that git is hard to use, and Inform can help a little with that.

Another modest gain in usefulness is that multiple versions of the same extension can now coexist side by side:

• Extensions/Emily Short/Locksmith.i7x

• Extensions/Emily Short/Locksmith-v3_2.i7x

• Extensions/Emily Short/Locksmith-v4_0_0-prealpha_13.i7x

Ultimately, where I want to go with this is that extension authors will post their extensions as GitHub repositories with semantic versioning tags, and inbuild will be able to fetch from them. At that point it will be a full-on package manager, the need for which I talked about at Narrascope I. We’re not there yet, but the infrastructure is coming into place.

Underpinning this is that Inform now follows the semantic version numbering standard 2.0 in full, except that it allows “version 6” to be an abbreviation for semantic version 6.0.0, and so on. If you have multiple copies of an extension then Inform uses semantic versioning to choose the most recent compatible one for a project, and so on.

This slide shows the current semver for this Tuesday’s internal build of Inform 7 – as you see, the traditional number-letter-number-number build code lives on, but only in the plus field. The next public build will be 10.1.0; that dash-alpha part shows that I’m alpha-testing it.

Something else enabled by Inbuild is Basic Inform, a version of Inform stripped down to be a programming language with no interactive fiction features.

This meant dividing the old Standard Rules extension in half. The first is called Basic Inform, and defines the language itself; the second is still called Standard Rules, and does all the narrative business of actions, the world model, and so on. Inbuild also introduces the notion of “kits”, the green jigsaw pieces here. These are precompiled packages of Inter code, which Inbuild incrementally compiles as needed. You can write your own, if you want to.

In Basic Inform, all of the stuff involving command parsing and the world model disappears. You can’t say “The Gymnasium is a room”, or “The player is wearing a silk hat.” That might seem like Hamlet without the Prince, or like apple pie without the apple. But modularising Inform like this means it can be used to make different sorts of games, or different sorts of art. It would be really interesting to see Inform used as an accessible front end for the visual art language Processing, for example.

Just as a treat for those who do like Hello World programs, here it is in Basic Inform. I cannot tell you what a technical challenge it was to get to the point where this worked.

My final phase of engagement is when people want to know how the program works: initially just from curiosity, but eventually some people want to be part of the crew, part of the inside loop. Obviously, that requires access to the internals. You can’t work on the engine of a car if you can’t open the hood.

On the other hand, in today’s world you can’t work on the engine of a car anyway, because it’s so opaque and complex. I look at this and think, well, somebody knows what they’re doing, but it certainly isn’t me.

This is the paradox of modern open source. Never have so many large programs been so openly readable as now. But their size and complexity is defeating. Their structure is often unexplained. They’re full of unfathomable relationships which are implied by the code but never explicitly written down.

Many people love the aesthetics of mathematical abstraction when they look at software. A beauty cold and austere, you might say, like the perfect way this car engine all interlocks.

And I do feel that lure. But real-world programs are about the fuzzy needs of real humans. I don’t think the ideal presentation of a program is a proof that it is mathematically correct. Instead, I’d like to borrow a standard tool from the social sciences.

That tool is the “thick description”. The term is attributed jointly to Gilbert Ryle and Clifford Geertz – I’ve never known how to pronounce that. It broadly means: describe not just the facts, but also how people understand them or behave around them.

This has been applicable in a surprising range of fields. For example, the archeologists excavating the world’s oldest city, the Turkish city of Çatalhöyük (I also don’t know how to pronounce that) do all the photography and mapping and digging you might expect. But they also keep diaries about their own feelings about what they find. A thick description of Çatalhöyük involves empathy, it’s about what it was like to live there.

At the other end of technology, Diane Vaughan’s classic study of the decision to launch the Space Shuttle Challenger gives a thick description of the meetings ahead of time, when engineers were worried but went ahead anyway, and the Shuttle was lost. These meetings were endlessly picked over afterwards, but most journalists and enquiries thought that slides like this one were evidence all by themselves. That was the classic example of a thin description, and Vaughan’s study is by far the best analysis of the disaster because she interviewed hundreds of people to ask questions like “how do you think about charts like this?”. So this is another example of a thick description.

So now let’s think about software. For me, simply posting source code of a program is a thin description. A thick description needs all kinds of other material all well: reasons why things are as they are, practical usage data, meaningful discussion of why defaults are the way they are. For most of the world’s software, materials like that are hard to find, if they are written down at all. They live in old SIGPLAN history articles, or archives of mailing lists, or in books like Bjarne Stroustrup’s “The Design and Evolution of C++” which end up being years out of date.

So how can we give a thick description of a computer program, make it accessible to people, and not have it fall hopelessly out of date?

That requires an organising tool, and one which binds the non-code and code materials closely together: as I’ve said before, my belief is that literate programming is ideal for this. I won’t go into details, because I talked about this at Narrascope I, and also in my London lecture the year before, both of which are on the Inform website. For now, it’s enough to say that Inform uses a literate programming tool called “inweb”, which presents a program as, in this case, a website – a website that’s updated every time code is checked in, and always represents the current state.

This slide – details don’t matter – is the contents page for the website version of a tool called Intest, used for testing Inform. And it does, of course, contain the full source code for the program — organised into chapters and sections with names which are legible to humans, and presented in a narrative sequence. But it also contains documentation, and command-line help text, and commentary about practical experience, and advice on how to make changes.

The most important “section” of the code contains no actual code at all, and is just called “How This Program Works”. This is heavily linked to the actual code it talks about. Again, it’s fine if this page is fuzzy over Zoom; the point is that those blue links click through to the functions of code they talk about. The literate programming tool ensures that none of these links ever break. Your program won’t compile if they do.

Another example of a web containing material which isn’t code as such is the “Performance Metrics” page from the Inform 7 web. This shows, for example, that only 9 of the over 100 compilation stages take more than 1% of the compiler’s running time. It also shows how memory is used, revealing, for example, that the syntax tree is about 15% of memory consumed. This too is part of a thick description.

More typical actual code looks like this — this is a tiny demonstration program which does nothing much.

Whereas this is an actual piece of production code — it’s the function in the Inform compiler which combines the subject and object clause of a sentence with its verb to form a proposition in predicate calculus. In effect, this is the point where the meaning of a sentence is finally understood.

Literate programming doesn’t have to be just for currently live programs: it’s also a way to study old ones. In the early stages of the lockdown, when my brother Toby was recovering from COVID-19, we did a little work over Skype each evening on presenting a commentary for an existing program. Toby had disassembled and puzzled out the ROM for a 1981 computer called the BBC Micro, but wasn’t sure how to present his findings. Literate programming turned out to be good for this, and what could have been an unreadable assembly language file is instead turning into a lively website of interlinked code, with downloads, photos of what the underside of the keyboard looks like, audio of what getting an extra life in Zalaga sounded like, videos, bits of historical documents, and little BBC Micro programs to try out. You could imagine a program like that becoming a kind of museum exhibition. But such a program can still be compiled.

Inweb lets you mix, for example, YouTube or Vimeo videos right in with code. Maybe the best commentary for user interface code comes in the form of videos showing what the animation actually looks like, after all.

Or, for those who are indeed writing algorithmic code needing justification, you can include mathematical proofs of what you’re doing.

So this is where I have got to. There’s still work to do, but all of the fundamentals are in place. My main publication is a thick description of a roughly 300,000-line code base, which will probably be the largest literate program in the world. I now know exactly how I’m going to publish it, and the tooling is working well. I work with drafts of the entire thing every day, which wasn’t true last year. The technical problems with the new Inter layer of Inform were considerable but they are now I think solved, which also wasn’t true at all at the time of Narrascope I. My intention is to publish the new version as a beta, alongside the generally reliable current build, so that nobody is trapped in novelty hell. And with that, I’ll invite questions.

There are people in this room who have been using one version of Inform or another for nearly thirty years. It was and is dedicated to two of the modern pioneers of IF, and this is one of those rare moments when we are together in the same room — Emily Short, whom I later married, and Andrew Plotkin, whom I have not as yet married. This isn’t the moment to give a description of Inform, but briefly, it’s a natural language-based system for describing situations and how to interact with them. Here’s a quick example.

… As you see, this sets up some physical concepts - length, area and weight - and some vocabulary to talk about them: the verb to weigh, the nouns length, area and weight, the adjectives light and heavy, and three scientific notations. For a single screen of code, that’s a lot. But I can skip to the next page really quite quickly, because you don’t need to remember any of it: it’ll all look natural in use.

Now we have a physical situation: a room with a balance platform and a couple of things to put on it. At the end is a short test script for some dialogue:

And there it is. A complex physical world which we can interact with, in just a couple of minutes. There’s a lot more to Inform, but you get the general idea.

In a quiet way, Inform has become quite widely used. According to the TIOBE index, a measure of popular usage of the world’s programming languages, Inform ranks sometimes right at the bottom of the top 50, sometimes somewhere in the second 50. Charts like this are dominated by the big general-purpose languages, C, C++, JavaScript and Python, and the usage curve falls off logarithmically fast. Being 50th means being orders of magnitude below the winners. Still, only a handful of domain-specific languages appear in the top 100 - Mathematica is the other one hovering on the top 50. (Twine would almost certainly also be in this range if it met the slightly narrow definition of programming language used by TIOBE.) Something else Inform and Mathematica have in common is that they are closed-source, whereas most modern languages have open source reference implementations. But Inform won’t be closed for much longer, and that’s my topic today.

I will begin, if I may, with a few reflections on large software projects, and how we think about them, versus how they really are.

The analogy we use is often architecture, and we like to use words like “architect” or “builder”, and “foundation” or “support” or even “scaffold”. In the absolute freedom of our text editors, we can make perfect constructions with elegance, permanence and function. We like the idea that a sketch becomes a blueprint becomes a building, all perfectly planned out.

Of course real software projects aren’t like that, and I think it’s instructive that real buildings aren’t like that either. One that’s going up now is Gaudi’s masterpiece, the Sagrada Familia cathedral. Here are the cranes at work:

In October, the project was granted a building permit by the Barcelona city council; and not a moment too soon, since they broke ground in 1880. Some of the most basic issues about this building are unresolved still. For one thing, how will anyone get in, or even be able to see the Glory Facade? It’s blocked by neighbouring housing. And most visitors may think the cathedral is nearly done, but the central spires, scheduled for 2036, are going to be twice that height. If you visit on a weekday, there’s a constant noise of cutting and you can get a faceful of stone dust. The Sagrada Familia is, in short, simultaneously a cathedral and a building site.

As you look at it, the first thing that hits you is the head-rush of seeing genius at work: proper Renaissance-grade genius, with the arrogance that goes with that. The second thing is that it’s a patchwork of old and new stone, built in fits and starts. That makes it a locus of argument and disagreement. The Passion Facade, seen here below the arch, was a very controversial addition in the 1970s. But even if Gaudi’s original plans had been complete, which they weren’t, they wouldn’t now make much sense. He couldn’t have imagined digital stone-cutting mills, which they now use. More delicately, he had no conception of how much society would change while the building was going up. When he was asked about the slow pace of building, he famously said: “My client is not in a hurry.” But in truth, his client has changed. The Sagrada Familia is headed for a future as a tourist destination, and it needs ticket kiosks and turnstiles and a coach park.

Isn’t this also how a lot of software projects go?

Just on that last point, Gaudi was run over by a tram in the street in 1926 and killed outright, leaving his papers and models in an unclear state. We all of us think we have more time than we actually have.

Where software is not like masonry is that nothing is irrevocable. You can rebuild the foundations while the towers hang in place in midair waiting for you to finish. You can, as it were, move the whole cathedral four feet to the left. But this is a lure. You always have to ask: am I making these changes for any good reason? So I want to explain why I have nevertheless spent the last three and a half years on an extensive rebuilding project. My previous maintenance plan for Inform went like so:

These annual stints of rewriting were somewhere between gardening and jungle clearance. Much of it was trying to make linguistic concepts mesh better with Inform’s data structures, especially in the early days. One summer I spent a week sitting at a table on the terrace of a villa near Menton, looking out at the Mediterranean —

In point of fact it was an awful shack, with vipers living in the grass, and it was a two-hour climb down to the sea, and a four-hour climb back again. Still, for one solid week, I unified the two different data structures for kinds of value and kinds of object. This was a frighteningly large refactor, but it ultimately removed many edge cases from the language.

Eventually, though, every old building reaches a point where routine maintenance is not enough. The only option is temporary closure, and scaffolding, and promises of a grand reopening.

Inform reached that point in 2015. It wasn’t closed in the sense of not being taken out of use, but it stopped offering new features. It will reopen later this year. I am open-sourcing it after rather than before this renovation because the work was so very disruptive, making major structural changes and touching almost all of the 250,000 lines of code. For long periods, sometimes over a month at a time, it couldn’t even build.

But not any more, and it’s time to take a look inside the scaffolding.

Inform as delivered to its users, via the Mac App Store, or direct download, or however they receive it, is a composite. This simplified diagram shows how code flows through various repositories. I am author and maintainer only of “core Inform”; the names in red are other team members. It took around three months of work to migrate the project to Github, and over 100 commits just to construct a cross-platform build mechanism. The two key decisions were: to have multiple repositories, or just one — I compromised on three; and to use git submodules, or not — I ended up deciding not.

To get started you need to clone and build three tools in turn: inweb, intest, and inform, so the instructions run for a few lines. But only a few, since Inform has no dependencies on third-party code. You need a modern C compiler, ideally clang, but gcc will do; and you need basic Unix tools. But that’s all.

Core Inform is written in ANSI C, properly speaking C99. That was the first decision I took, in 2001, and it was the wrong choice. I had my reasons, but C++ would have been better for the heterogenous tree structures you need inside of compilers. I feel much happier about my other early decision, which was to adopt literate programming.

Literate programming was invented by Donald Knuth in the 1970s: he was responsible for the slightly insulting name, as if all other programmers are illiterate. The idea is to write a program like an essay, with a narrative, so that its source code can be read by humans as well as computers. This is not just about commentary: it’s about making long or complex functions more comprehensible. Here’s the function at the heart of Inform, which glues sentences together from their subject and object phrases.

Note the “paragraphs”, shown here in darker blue. These then have expanded definitions, further down in the file. But the idea is that you can see what happens at one glance. In orthodox programming, you’d end up writing a lot of one-use functions with a lot of awkward names and parameters to achieve the same end. And here’s the definition of “Handle a THERE subtree”:

The necessary preprocessing to turn this into something which can compile in a C compiler, a process called tangling, is done by a tool called Inweb. This does other helpful things too: it removes the need for C header files and for predeclarations of functions, it adds a little modularity to C, and so on. Besides tangling, Inweb also “weaves” code into a human-readable form, such as a web page. Here’s the same passage in its woven form:

Literate programming is not a popular choice today. The canonical primers on software are respectful but basically tell you not to use it: “Code Complete”, for example, or “The Art of Unix Programming”. It failed to catch on for several reasons: most programmers do not like to write essays. Most code has a short shelf life anyway. Commentary in code is out of fashion these days, and some coders even consider it harmful.

But literate programming wasn’t as completely rejected as it might seem.

Some of the ideas do live on, especially in teaching environments, and they strongly influenced Inform’s design. LP continues to be used in some theoretically difficult software, such as the Axiom computer algebra system. The Axiom project adopted it because of their goal to keep the code understandable over a 30-year timescale.

I think they’re right to think in those terms. Inform is already 26 years old, and even Inform 7 is over 18.

Still, it must be said, proper literate programming is now hard to practice even if you want to, because there are no really first-rate tools for it.

The 1970s tools, written by Knuth, contain both hard size limits and heavy restrictions. They can’t really be used any more. When the World Wide Web arrived in the 90s, there was a second wave, of which the best are noweb and funnelweb. Noweb is still sometimes used, but these tools went to the opposite extreme, being too general-purpose to add much value. For what it’s worth, Inweb is being given its own repository independent of Inform, so at least there’s now another option out there. Quite a lot of work has gone into it over the last few years, so if you’ll forgive an Apple-style slide of features I won’t talk about:

Above all, it handles modules of code, which in effect are libraries for sharing across multiple projects. The inweb repository contains one module in particular which was built by collating together all of Inform’s lower-level support functions, thus moving them out of the main compiler. This module is called foundation:

Foundation provides the higher-level features you get in a more modern language, and that makes coding in C much more bearable. It also abstracts away issues like 32- versus 64-bit, and POSIX versus Windows file-handling and threading. All of Inform’s tools are now built on foundation, including inweb itself, which is why foundation is shipped in the Inweb repository, not the Inform one. Most notable here is the foundation provides flexible-sized strings of UTF-16 Unicode text; that was a dramatic change, and it took about six months to strip out all ASCII C strings out of Inform in favour of these.

The other sidekick repository is intest. This was once a hacky script tied entirely to Inform, but it’s now a general-purpose tool for testing any command-line software, so it too is offered independently. Tests follow multi-stage recipes, written in a language called Delia. If I were American, it would be called Julia.

Intest is used for testing all of the Inform tools, but its main party trick is to spread a suite of 2000 tests of Inform 7 across all the available cores on a modern computer. Each test only takes 3 seconds, but with 2000 tests and only 3600 seconds supplied in every hour, you really want to run them in parallel.

So much for the two sidekick projects, Inweb and Intest. Those are only two of the nine Inform command-line tools. The other seven are all inside the inform repository. The list as a whole looks like this:

These vary greatly in size. Indoc is 7000 lines, but Inform 7 is 170,000. They can all be used at the command line, outside of the familiar user interface apps, and they all follow standard Unix conventions. They also all have manuals.

My final structural change was the largest of all: I wanted to make Inform more useful. I began by asking myself a basic question: how do we make a program more useful, and widen its range of usefulness? Well: a program turns an input into an output, so you generalise the input, and you generalise the output.

This shows the input and output for Inform, which in some sense turns English language into interactive situations, via a lower-level language called Inform 6. Here’s what generalising the input would look like:

A great deal of work has gone into this. You can supply verb conjugations and inflections and natural-language grammars as alternatives to English, and so on, but it’s still immensely challenging. For one thing, Inform’s output is not just the code it produces, but also the Index and the problem messages. There are partial mechanisms for localising them, but we’re a long way from this dream being a reality. Open-sourcing should make it easier for people to work on this area.

So much for generalise the input; now, generalise the output.

This is the main change I’ve made. The Inform compiler has an entirely new back end, which generates an intermediate-level code called “inter”, and only then code-generates that into I6. (I6 is the Inform 6 language, which is much lower-level.) But Inter doesn’t have to be converted to I6: all kinds of other possibilities are now open.

Inter is handled by a pipeline somewhat influenced by the design of LLVM, and pipeline stages are easy to add. This makes it easy to experiment with optimising the code. For example, one evening I wrote a peephole optimiser to remove unnecessary Inform 6 labels: it took only a page of code, and reduced the quantity of Inter generated by about 2%. Similarly, a redundant code elimination stage reduces the size of typical story files by about 20%.

Until 2015, the way that Inform generated code was to write out a textual file in Inform 6 syntax, which I’m going to call I6 from now on. That was very fast, but meant that low-level compilation code was spotted all over the compiler.

That may seem surprising on the face of it. You might reasonably think that the functions produced by Inform correspond to the rules that it finds in the source text — one rule makes one function. And Inform does indeed make each rule into a function; but that’s only one out of the 91 different sorts of function that it needs to make for different purposes.

Suppose our example rule contained:

if a battery compartment which is part of the machine contains a battery (called the power source)

Inform tests that logical proposition with another function.

Well, there are 89 more needs like that, and there are hundreds of run-time data structures, mostly arrays. So it wasn’t a small undertaking to generate Inter instead of I6.

But I’m relieved to say that that project is now complete. For over a year, Inform generated hybrid forms of Inter containing raw I6 expressions (called globs) and raw I6 function bodies (called splats). When I spoke at the London IF meetup in 2018, I said that “it was a big day when Inform no longer generated any globs, and it will be a bigger one when it no longer generates any splats”. That day was 6 May 2019.

So what is Inter? Well, it’s an intermediate-level description of the program, which can exist in three forms: in memory, as bytecode; in a file, in binary form; or in a file, in textual form. For speed, Inform keeps Inter as bytecode in memory at all times, but you can add stages to the pipeline to write out the current state to a text or binary file. The inter command line tool faithfully converts between these three forms.

Inter is low-level, and therefore verbose. You wouldn’t want to write it by hand, though you can. A typical 1000-word source text — the example “Witnessed” from the Inform documentation, which is where these batteries come from — currently generates 285,606 instructions of Inter. That’s because of the enormous amount of supporting code needed to manage the world model, and to parse commands at run-time. Those 285,606 instructions then generate 81,736 lines of Inform 6.

This shows how a very small fragment is processed: a single line of Inform becomes a chunk of Inter and then some Inform 6.

Inter code is hierarchical: it is, in effect, as much like a final parse tree as a stream of assembly language. At the highest level, it’s a hierarchy of “packages”, each of which has a type. At the top level is main, which holds a number of packages of type “_module”. Some modules derive from natural language Inform code in a direct way: each extension leads to a single module, and the “source_text” module is what the main source text leads to. For example:

That little source text leads to a package of Inter that fits on a single screen. It’s in small type, but it’s 30 lines, not 290,000. As you might expect, this defines two physical objects in the spatial world model of a little interactive fiction. If we get rid of the details:

As this demonstrates, the hierarchy conveys something quite semantically rich, and enables us to locate resources within what may be a large tree of Inter.

If I run the Inter command-line tool on the output from Inform and use the -inventory switch, it will be able to tell me that there are two instances created in the source text.

And it can also tell us exactly what the different extensions bring to the party; here are some more instances, kinds and variables.

Each package is a little self-contained world, with all its references to other packages being made explicitly in a symbols table. Anyway: that’s enough to get the idea; the whole thing is documented in the Inter manual.

As a brief aside, though, I do want to mention the biggest challenge in doing all of this. The Inform 7 language contains some low-level features intended for use mainly by the Standard Rules, allowing you to define phrases using I6 code.

What are we to do with this I6 content? One option would be to rewrite the Standard Rules in some entirely new syntax based on Inter, and to rewrite the template files in Inter. Both would be problematic, and anyway many other extensions also use I6 phrase definitions, even if end users mostly don’t.

The solution is a technique called “assimilation”. Inform now contains an I6 decompiler, which converts it into Inter code. That’s not many words to say out loud, but it took quite a lot longer to get working. The practical effect is that although I6 syntaxes are still read in by Inform 7, they are used purely as a concise notation to express Inter. At present, that Inter is code-generated back into I6 again, thus completing the circle of life. But later on it may code-generate into other things.

The Inform documentation example “Uncommon Ground”, right at the very end of the manual, was very much the worst case scenario. It doesn’t look natural-language at all, because it shows a low-level way to define a multi-part text substitution. Those four phrase definitions collectively make an I6 switch statement. But not one of them is a syntactically valid piece of I6 on its own. Fragments like this are the hardest to assimilate.

Well, end of aside. I think it’s apparent that the 2015-2019 rewrite has been pretty dramatic in scale. That adds risk: people need Inform to carry on working as it should. To mitigate the risk, there’s a new Settings control in the app, allowing the version of Inform to be changed.

Turn it back to the 2015 version, and you get the 2015 compiler, template and extensions. We will support at least three previous language versions before the current one, and we’re working on going further back, for archival purposes.

So, then, that’s what has been done. It’s nearly there: I’m only a few momths away, and the next public release will certainly be in 2019. Simultanously with the next public release, the Github repositories will all be made public. I want to spend the rest of my time on open-sourcing, and where it takes us.

To recap, core Inform was migrated onto Github in December 2018, and by around March we had the new build process sorted out reasonably well. I’m confident now that it will be fairly easy to pull, to build, and to fork. The structure will be fairly sound and that code will, despite the complexity of what it does, be fairly readable.

But what then? The words “open source” sound simple enough, but they stand for quite a range of social practices. To begin with, there’s an actual contract: the licence.

This I think will be uncontroversial. The Artistic License is at the free end of the spectrum, closer to MIT than to the GPL. It’s like a software version of Creative Commons Attribution, where your only real obligation is to credit the authorship of the original. If you fork and change Inform to a different language, you’re obliged to call it something else. Two additional grants will be made, one clarifying the status of code output by Inform, one clarifying the license for Inform 6. No existing freedoms will be lost.

But a license is only the start. There will need to be policy on a host of uninteresting practical questions. What bug-tracker to use? Do we stay with Mantis? Who will manage bugs? Will release downloads be hosted at the core Inform GitHub pages? What happens to the existing inform7.com? Will we offer app downloads on unstable branches, or just for public releases? How do we cope with increasing issues on MacOS to do with code-signing, sandboxing and notarization?

[Discussions after the talk also led to the question of copyright: on some projects contributors assign copyright, and on some they don’t. For Inform the consensus was that it’s best to have a single copyright-owner, currently myself, so that we have the option to transfer this copyright to the Interactive Fiction Technology Foundation at some later time. Because of that, contributors will probably need to assign copyright.]

A thornier question is: what is the gatekeeping process for new features?

In most open-source programming languages, there’s a proposal system, and a set of social practices whereby people debate the merits, try out an implementation of something new, and then decide whether it’s in or out. As the recent affair of the Go package manager shows, it’s all too easy for the creators and the contributors of an open source project to misunderstand each other entirely. I think it’s best to set out expectations from the beginning.

I’m not open-sourcing Inform as a way of walking away: I intend to remain its overall designer. Projects which lose their leaders, for want of a better word, tend to stumble because there’s no oracle to go to for a ruling. Even in languages where the creator has ostensibly ceded control — Python, Swift, or Perl — the creator generally remains a power behind the scenes. I think it’s better to be up front about that: I’m going to have the last say on what goes in.

More positively, though, I hope to publish a document giving a list of general areas where volunteers might take a look. It’s probably good at first for people to contribute bug fixes and get their bearings in the code, but here are a few possible examples of more ambitious projects.

Inform is quite often used in the games industry for mock-ups of interactions: it’s a way to storyboard the sort of interactivity which will eventually be achieved by other means. But what if Inform could actually be used directly to provide final implementations inside games? In other words, as a middleware component in, for example, Unity? I’d be interested in working with a game developer who wanted to try that.

Nowadays most programming languages would benefit from package managers, and so would Inform, though in our case it would be an extension manager. We have that, in a primitive form, as the Public Library in the apps. But it would really be better to have a clearer idea of versioning, and to be able to fetch extensions from appropriate branches in public git repositories.

At present Inform story files are played more often in browsers than in interpreter apps. That means they are interpreted in JavaScript code by a program called Quixe. It might be interesting to compile from Inter directly to Javascript, in a way which incorporates large chunks of Quixe. Other target languges might also be interesting: the visual art language Processing, for example. Imagine using Inform-style natural language to describe the art you want to make.

Lastly: There’s currently no Inform app for iOS, and it would be very nice to have one. Inform for Android showed that people may actually quite like the experience of Inform for mobile; especially for something like an iPad with a keyboard case.

Well: so having begun with a slide of Boston Commons in Spring, I leave you with a slide of Oxford in Autumn — a movie-style Coming Soon poster for the open sourcing. Inform 1 was created in the sandstone building just behind the junction of Longwall Street, in the upper left. So that is where it all started, and this is where I will now end.

Some of the details about future plans have moved on: see the June 2019 Narrascope talk for an update.

Firstly, of course, thank you for coming out on a Saturday night. I’m really going to give two short talks, one after the other. In the first half, I want to give my own assessment of the Inform programming language, and you must allow for the fact that I am Inform’s creator, and not an unbiased commentator. In the second half, I will turn to what’s wrong with Inform as it stands, and what the plan is for its further development, and in general what I’ve been working on for the last three years, off and on. In that part of the evening, you’ll have to allow for the fact that I am Inform’s maintainer, and therefore in a permanent state of guilt and anxiety about it.

Inform is a domain-specific language, and its domain is the creation of interactive fiction. When it began in 1993, Inform was simply a new hacker tool for making what we used to call adventure games: that is, textual games with a turn cycle in which the player typed commands and the game then revealed an appropriate piece of story — a story partly generated dynamically, but partly following a narrative already laid out by the author. This is a genre of writing which began with recreational computing in the 1970s, then passed through a commercial phase in the 1980s. Inform is called Inform in part because of the classic works of a company called Infocom:

The best of their roughly 35 interactive fictions, a term that Infocom coined, remain enjoyable today. They are pleasing as a piece of Americana — like the movie Back to the Future, the Space Shuttle or the first Apple Mac, Infocom is a slice of the America of the Reagan administration — but they are also, on a good day, successful both as games and as art.

The rise of graphics hardware and a downward slide in the average age of games players made the text adventure commercially extinct by 1990, but this was both an end and a beginning. The countervailing factor was the rise of networking: University student access, home dial-up, bulletin boards, Usenet, magazine cover discs, the web, home broadband, and so on. At the earliest possible opportunity, hobbyists, for want of a better word, took up the practice of writing and sharing interactive fiction of their own. By 1993, a home PC could just about compile a work of IF of the size and complexity of the works which Infocom had needed a mainframe for in 1983. All that was needed was a compiler.

The 1990s were a propitious time for this sort of hobby computing. There were really two computing bubbles in this era. The one people talk about was the dot-com boom, when the potential of websites hit the venture capital market, and startups like Amazon got going. The other was an almost ideologically opposite sort of economy, with the rise of Linux, Perl and Apache, a market in which your wealth, in the form of public standing, was proportional to how much you had given to the community, in the form of code. Jeff Bezos got to be a billionaire out of the 90s, but thanks to my software, I got to marry Emily Short, so you could say we both got to be the world’s richest man.

Not much about the original Inform language was original. It was a C-like language with classes whose compiler could have been a summer project for a graduate student, which is what I was in 1993. Still, it was shaped by the experiences of real users, and iterated rapidly through versions 1 to 5, stabilising as Inform 6 in 1996. When, in 2003, I returned to the problem of making IF, I threw away the entire Inform language and began again, but called the result Inform 7, the next available major version number. I slightly regret that now, in the same way that Apple came to regret calling Mac OS X simply version 10 of their famous operating system, when in fact it was a whole different thing. But it was probably a good decision at the time. ‘Inform’ was my brand, and making it ‘Inform 7’ was a way of declaring that Inform 6 was officially over. (This didn’t work for Larry Wall when he tried to replace Perl 5 with Perl 6, but that was because Larry hadn’t actually written Perl 6 at the time.) At any rate, Inform 7 had its first public release in 2006. It was heavily shaped not only by me, but also by Andrew Plotkin, a long-time member of the Boston IF scene, whom some of you may know, and by Emily Short, our host tonight.

So, then, Inform is available for Linux, Mac OS X, Windows and Android. Apple’s rules exclude it from iOS, but it has otherwise been on more or less every platform. The Mac App Store version gets about 2000 downloads a month, to give some idea of scale. If we look at the TIOBE index, a measure of usage and influence among programming languages, Inform’s best result was 49th, in 2015: just above Mathematica, and just behind FORTRAN. (For comparison, the 49th most spoken natural language is Romanian.)

Being in front of a large number of users means that your software has a large number of bugs, in the sense that a bug is a defect you actually know about. The more people participate, the more bug reports you get. My favourite was turned in by the Canadian computer scientist Daniel Fremont, whose research is in finding software defects, and who managed to crash Inform in 2014 by fuzzing it with a program consisting of the sentence ‘Foo is a room.’ repeated 117,030 times. (Other numbers of repetitions didn’t work.)

At certain times of year, fixing that kind of thing is how I spend my evenings and weekends. There’s always a tension between making forward progress on the software or fixing bugs, and to some extent, you have to ask what benefits actual users the most. But a crash is a crash. I did fix Daniel’s bug.

The chief originality of Inform 7 is that it is based entirely on natural language. I want to sketch out some of the motivation for that, and some of the benefits that come from it.

To compare programming languages with natural languages is a little heretical in computer science, but I’m not sure why that is. The development of the theory of programming languages was, after all, spurred on by the early work of Noam Chomsky.

Thus, for example, Donald Knuth took Chomsky’s book on structural linguistics with him on his honeymoon. In spite of this Don is still married to Jill, 45 years later: when you have dinner with the Knuths you talk more about quilting and printing Lutheran bibles than programming, but it all seems of a piece.

I mention Knuth because, of all the Old Masters of computer science, he is the one most interested in the relationship between computer programs and texts. Could we even suggest that a program is a text? It is, after all, a written expression of creativity. Certainly, when running, a computer game can be an artistic experience in the same way that a film, or a play can. But my concern here is not whether the program is art when it runs. I’m talking about whether its source code is a text. We could go down a bit of a rabbit-hole here about playful literary theories. Umberto Eco once reviewed a new Italian banknote as a work of art, describing it as a numbered, limited edition of engravings. But let’s concede that a functional document like a shopping list or a spreadsheet of student names is not a literary text. On the other hand, a recipe by a literary cook like Elizabeth David might be art, even though it also has function. Perhaps the relevant question is: can we experience a program as a text? Can we, in the fullest sense of the word, read it?

A cynical answer might be that if program source codes are texts, why can’t you buy them in a bookshop?

In fact, annotated editions of a handful of programs have indeed been published, most notably TeX and version 6 of the Unix operating system. Two large-scale Inform programs have also been printed in book form. Modern programs can be enormous, of course, and would be unwieldy as a physical book, but even these are often freely readable at repositories such as Github. So I don’t think it could be said that programs aren’t read as texts because they aren’t available.

The problem is rather that source-code spelunking, as it’s sometimes called, is so unrewarding. You pick a file from a mass of files, hoping to get your bearings, but open it to find endless low-level manouevres. There are some suggestive class or function names but it’s hard to get a sense of even the basic plan of how it works.

This problem is made worse, I think, by the aesthetics, or perhaps I should say the ideology, of many working programmers. All programming languages provide for comments, but coders often want to purge this marginalia, disliking any verbose comment as a form of ‘cruft’. It violates, they would say, the ‘Don’t Repeat Yourself’ maxim.

‘Don’t Repeat Yourself’, or DRY, is taught by many make-yourself-a-better-programmer books — a genre of publishing which always reminds me of relationship self-help books. DRY says that the same concept shouldn’t be given more than one expression in the code. But taken to extremes, DRY means that any comment saying what a program is trying to do is redundant, because a program is by definition already a statement of what it does. Don’t repeat yourself, in other words, can be taken to mean: never explain yourself.

I am a contrarian on this. My own programs are written using the doctrine of ‘literate programming’ — an unhelpful name today, implying a bit aggressively that everybody else is illiterate. The name comes because Knuth propounded the idea as a sort of rejoinder, or qualification, to the rise of ‘structured programming’, a practice advocated by the European school of computer science: Edsger Dijkstra, who was Dutch, Niklaus Wirth, who was Swiss, Tony Hoare, who was English. Structured programming calls for programs to be organised into modular parts, rather than being one big soup of instructions. Knuth didn’t disagree, but he seems to have felt that this took away from the sense of a program having a narrative, what we might call a linear plot. In older programs, a human reader could often start at the top, see how it begins, what it does, and how it finishes, following its execution in sequence. By contrast, one reason it’s hard to figure out what’s going on in a big modern program is that it’s more like a landscape than a story. It’s an expanse you can wander about in any direction, never being quite sure what is collectively achieved by the too many components, or in what order. This is not to say that structured programming is a bad thing: I believe it’s essential. But it is not self-explanatory.

Knuth proposed literate programming as a way to explicate programs. He gave an elegant statement of this dogma in 1992, when invited to write an encyclopaedia entry on programming. I like this quote, because it’s so antithetical to what almost everybody in computer science thinks, with a few honourable exceptions (some tools for Haskell, for example, are influenced by literate programming).

Literate programming, then, is a set of tools and practices to mix code with explanatory text. Source code is a blend of code and explanation divided into linked pieces and called a ‘web’. This doesn’t refer to the Internet — it’s actually an earlier usage. There are two fundamental operations on a web: ‘tangling’, which turns it into regular code to be compiled or interpreted; and ‘weaving’, which turns it into a web page, an ebook or a PDF.

How did literate programming influence Inform? Well, one answer is that is that Inform’s equivalent of a standard library is intended to be human-readable. Whereas (say) the C++ STL, or the ANSI C library, are by design opaque to users and presented as APIs, the extensive suite of software supplied with Inform comes as a set of about 500 ‘examples’ — short, readable, copyable and easily lifted from, and presented with commentary.

But the deeper answer is that Inform aims to go further by merging the commentary on a program, written in English, with the program itself: it uses natural language throughout. Inform is of course Turing-complete, but it’s not primarily intended to solve conventional tasks: it’s for the creation of simulations of human situations — which, at some level, is a definition of art.

So let’s now take a look at Inform from a natural language point of view, and start with nouns. Here is a rather minimal Inform program:

Of course the result is not a rich interactive experience, but we’re just getting going.

Now we have a proper noun, Snell Library, and a common noun, student. Proper and common nouns appear in regular programming languages as instances and classes. Languages like C++ or Java aim to police the boundaries of class definitions, and as computer scientists we seem always to want stricter policing, even though we also want to have it both ways with dodges like generics or protocols. Work in linguistics might suggest that we should be less doctrinaire about common nouns and what they describe. In Inform, the concept of ‘kind’ approximates ‘class’, but it was also motivated by the work of the great Polish linguist Anna Wierzbicka. Wierzbicka studies how people make, and then selectively break, categories. A famous example is her definition of the common noun ‘bird’:

Of course an ostrich or a penguin is a bird which doesn’t fly. For Wierzbicka, there’s no contradiction in that: people naturally make semantic categories and yet allow members which violate one of the defining characteristics. You can see something similar in this fragment of Inform:

Note the word ‘usually’. I would suggest that work like Wierzbicka’s might shed some light on long-standing controversies about single versus multiple inheritance in object-oriented languages.

Let’s go back to the simple-looking sentence ‘There are ten students in the Library’, which has quite a lot going on. For one thing, the ‘there’ is a defective form in English, like the ‘it’ in ‘it is raining’, except to emphasise that an existential statement is being made. Inform internally reduces this sentence to predicate calculus, which serves as what linguists call our ‘discourse representation’.

Here I follow an important early-1980s paper of Barwise and Cooper which observes that the basic logical quantifiers ‘there exists’ and ‘for all’ are inadequate for any sensible representation of natural language: Barwise and Cooper added new quantifiers such as ‘there exist 10’, or ‘for most’. Anyway, the proposition says that there are 10 different values of x for which ‘student(x)’, x is a student, and ‘inside(x, Library)’, x is physically located inside the Snell Library.

These basic factual statements, like ‘student(x)’, are predicates. If they involve only one value, like ‘student(x)’ or ‘evasive(x)’, they’re unary predicates; if they involve two, like ‘inside(x, y)’, they’re binary. Skating over some grammatical niceties about common nouns and prepositions, unary predicates are adjectives and binary predicates are verbs.

Given that almost all of the meaning of natural language is conveyed by binary predicates — verbs, that is — it’s striking how much traditional programming languages downplay them. Object-oriented languages, in particular, greatly over-favour unary predicates at the expense of binary. To explain what I mean by this, consider the following piece of Inform:

These few sentences do quite a lot of work. ‘Sophie likes purple’, for example, creates both the person Sophie and the colour purple, whose existence Inform has deduced from the fact that they are connected by the binary predicate ‘liking(x, y)’. In a typical Java or Python program, you would have to simulate this either by putting lots of code about colours into your definition of people, or vice versa, which is a convoluted way of trying to use unary predicates instead: either ‘sophie-likes(x)’ for x = purple, or ‘purple-is-liked-by(x)’ for x = Sophie. Either way round, that’s unnatural, I think. Inform sees binary predicates like ‘liking’ as being first-class concepts in themselves, not as behaviours of either participant.

I think it’s striking, too, that most programming languages have a muddy understanding of adjectives — properties that things either have or don’t have. These tend to be boolean flags attached to objects, making them values as though they are the result of calculations, or else are awkwardly accessed by methods like these:

Which often read ambiguously: does ‘F.atEndOfFile’ change the state, or test it? Are there side-effects? Programmers can often only express these important distinctions by choosing method names carefully — all large companies have a style guide with rules like that — but because this is not a feature of the programming language, compilers don’t police it, and many mistakes are made as a result.

In Inform, on the other hand, one would test or change with syntax such as:

And in general, the syntax to make something happen is the same as the syntax to test it, but using ‘now’ instead of ‘if’. For example:

Note the way that such conditions, by including determiners such as ‘all’, can avoid the need to create and name spurious loop variables. ‘now all of the students are in the Library’ is easier to understand than making a repeat loop, with a necessary but in some sense meaningless variable called S. Anything which reduces the stock of nouns in play makes code easier to understand.

As will have been evident, a guiding design principle for Inform was to imitate the conventions of natural language. But not simply language as we speak it: I also mean the conventions we use when we write and publish it. For example, standard computer programs contain far too many literal numbers and blur together what they’re used for, which causes many errors. Numbers ought to be as rare in programs as they are in speech.

With only a handful of exceptions, natural language uses raw numbers only to count things. We say ‘I am 176cm tall’, not ‘I am 176 tall’. We say ‘My car weighs 1.4 tonnes’, not ‘My car weighs 1.4’. In Inform, you can say something like this:

Moreover Inform uses dimensional analysis to stop you muddling up numbers in ways which wouldn’t mean anything. You can’t add a length to a mass, for example. Nor can you use a mass where you need an number. If you want the mass of the Clio as a number, divide it by 1kg. You can only multiply if you’ve clearly explained what that would mean. For example, write:

and then you’re allowed to multiply them. It was quite a fun bit of physics-nerdery to work these algorithms out. I don’t think I had ever realised that voltage, for example, is not a fundamental unit and that the ‘volt’ is only a sort of verbal shorthand. When your smoke detector runs down, you do not think ‘where have I put my 9 m^2 kg per amp per second cubed batteries’.

Inform also follows natural language conventions as seen in printed texts. You can lay out equations the way they would appear in a textbook, for example; or consider this rather minimal simulation of the Tour de France:

Here we see square brackets used to mean text which isn’t a verbatim quotation, and we have a table of data laid out just as it would be in a book. Tables do not serve every need — Inform also has lists, for example. But I think tables are a form of data structure immediately comprehensible to a human reader, in a way that arrays are not.

Most programming languages have nothing analogous to tenses: everything happens in the present tense. We code about the state of the world as it is right now, and say what happens right now. While it’s understandable that we don’t talk about the future — we can’t meaningfully perform the test ‘if X will be 6’ — it’s more surprising that programming languages do not support ways to refer to the past, because we need to do that constantly. What we do instead is to create variables, giving them names, and write cumbersome code to store data in those variables which we are going to need later on. Then, later on, we inspect the contents of those variables.

Inform suggests that there are partial gains to be made by supporting past tenses in the language. For example, in Inform we can write:

The compiler takes care of all of the supporting code and storage needed — we need nothing other than that line. In effect this line is equivalent to writing separate code, elsewhere in the program, which reads:

At any rate, Inform provides what amounts to a fourth boolean operator to modify conditions, beyond the usual and, or and not: an operator placing the condition in a past tense.

However, I said this was only a partial win. As linguistics people have realised since the pioneering work of the Danish linguist Otto Jespersen, resolving a name — in effect, dereferencing a pointer — has different results at different times. This leads to ambiguity.

The problem here is that ‘the President’ is a variable, reflecting that the Presidency is held by different people at different times. We must evaluate this variable. But when? If we evaluate it in the past, the condition means ‘if the sitting President has ever been ill while in office’, and will be true if Dwight Eisenhower caught cold in 1955. If we evaluate it in the present, the condition means ‘if the current President has at any point in his past been ill’, and will be true if, for example, Donald Trump had measles in 1975.

But this latter interpretation has serious consequences. When we are able to perform the measles test, back in 1975, we have no way of knowing that Trump will be President. That means we have to test everybody, all of the time, just in case they turn out to be President some day. That requires a lot of storage and incurs a heavy run-time speed penalty. Inform therefore reads ‘if the President has been ill’ as the question ‘if it has ever been true that the sitting President is ill’, which is cheap to test and can be stored in a single bit. Nevertheless, that may not be what the author intended; and evaluating variables in the past is problematic if ‘the President’ is not a global variable, because you can’t evaluate it in the past if, like a local variable on the stack, it didn’t exist in the past. These questions are much subtler than they appear, and are the reason why Inform doesn’t go further into the world of tenses than it does.

I want to mention one other aspect of natural language which can be troublesome for programming: punctuation.

Conventional programming languages, such as C, are aggressively punctuated. By this I mean not only that C code is replete with commas, brackets, braces, semicolons, and colons, but that other requirements — such as that identifiers cannot contain whitespace or use reserved words — combine to produce an apparently unambiguous language. And this has many advantages.

But at first sight, natural language seems almost completely the opposite: it is riddled with ambiguities.

My favourite was an actual headline in the local newspaper in my home town, the Oxford Mail: HEATWAVE BONE BREAKS CLOG HOSPITAL, which is what linguists call an a garden path sentence; or there’s the famous antanaclasis ‘Time flies like an arrow; fruit flies like a banana’. If English had a form of punctuation marking which words are verbs, such ambiguities would be impossible.

And because of this, many computer scientists are wary of natural language as a way to express a computer program. In fact, though, the situation is not as clear-cut as saying that a language like C is precise whereas English is a lottery. C is very ambiguous in resolving nouns. There’s nothing to prevent multiple functions being called ‘printf’, and this has to be resolved using scope and namespaces. An identifier for a variable is not syntactically different from an identifier for a function, and this has to be resolved by looking at its meaning. In both cases, ambiguity is resolved using an understanding of the context in which the usage was made. That is exactly how natural languages function, too. So the difference in ambiguity between programming languages and natural language is one of degree, and is not an absolute.

To conclude this first half of my talk: did natural language turn out to be a good way to write a computer program?

The merits are: familiarity; a low barrier to entry, so that novices, even schoolkids, can get at least something to work quickly; conciseness, in that a lot of boring code becomes unnecessary; and perhaps a greater ease of expressiveness, because the lineaments of the language more closely follow our cognitive habits than would be true of, say, C++.

The demerits are: unfamiliarity, in that we’re not used to coding in prose; a high barrier to entry, as a result; verbosity, in that some arithmetical or data-heavy computations probably are better expressed in formulae; and perhaps, greater ease of expressiveness, which though it’s a good thing in some ways can also lead us casually to write inefficient code.

So I freely acknowledge that the benefits are double-edged. But they are real.

Let’s look at the Inform project as it stood in 2015. As has been widely noted, it hasn’t been updated in the last three years, and the reasons for this will become clear in the second half of my talk. If we stood back in 2015 and asked, is Inform successful?, what should we say? Here’s the optimistic view first.

With all due modesty, I think I can claim three successes for Inform.

(1) It reduced the barrier to entry for would-be writers of interactive fiction. So, in a different way, did the wonderful tool Twine: I’m not by any means claiming any unique virtue here. But welcoming in beginners is important. It’s not an accident that Inform and Twine, between them, account for most of the writing being done in this genre.

(2) Inform has been a sort of laboratory: a testing ground to see if natural language is possible as a means of coding. Some features from Inform have made their way into other programming languages. Inform has also been a sketch-pad: it gets used for purposes other than IF, such as procedurally generated text, or prototyping in the games industry. There is no triple-A game written in Inform, but there are several whose mechanics were sketched out with it.

(3) Finally, what I’m proudest of, when I look at Inform, is that it has been used to make a great deal of art. Inform has made somewhere between 1000 and 2000 finished works of art (not counting little examples and demos, or classroom exercises, or homework). That’s a small number in computing, but quite a large number in art. It’s about the same as the total number of plays ever performed at the National Theatre.

Now I’m going to say what I think is seriously wrong with Inform in its current public release. It was very well tested and is widely used, but that is often true of software in need of generational change. As I looked at Inform in 2015, I saw a number of existential crises facing it — by which I mean, issues that threatened to end its life for all but antiquarian purposes.

One thing to remember that I am a self-taught amateur programmer…

…and that I have a day job, actually two day jobs. I can’t devote my whole attention to Inform. But that said, I do continue to work on it, and rumours that it is rusting forgotten in a tool shed are exaggerated.

(That cartoon was xkcd 1513: Code Quality.)

With that disclaimer made, I’m going to get into the internals, just as I knew what I were doing. I talk about Inform being in crisis, I should first say how Inform worked in 2015. The user sees a friendly Mac, Windows or Linux app, but that’s really just a wrapper on top of some lower-level tools. When you click ‘Go’, the source text is translated into a website or story file by a series of programs, each transforming it in turn:

So what was wrong with that? Well, plenty:

(1) ‘inform7’ did far too much for one stage. The code was hard to isolate faults in. It had become the classic oil tanker that takes a long time to turn around. In part that’s because it was and is written in ANSI C, a portable but low-level language making it difficult to abstract high-level concepts. It has been refactored many times — once every year, I ask myself, what is the worst design decision in this program?, and then change it — but too many data structures express only parts of an overarching concept, with that overarching concept somehow not being visible in the code. (‘Adjective’ would be a good example of this.) In short: ‘inform7’ was too big not to fail.

(2) Being written in C is not a threat in itself, but like many old C programs, inform7 was prone to insecure string-handling and erratic Unicode support.

(3) Although the tools in this chain were in one sense independent, they were cranky to use without the Inform UI as life support system. They were also inconsistent in niggling low-level ways — handling long filenames, say, or filenames with strange Unicode in.

(4) The unreleased tools needed to build and test Inform were far worse, some being huge Perl scripts which were just mazes of twisty little passages. They were nowhere close to being releaseable in quality. One reason Inform hasn’t been open source in some years is that this infrastructure was such a mess. But not being open source is an existential threat right there.

(5) Inform makes something that people don’t always want: a work of parser-IF sealed up in its own virtual machine is great for classical IF authors — the ‘playable story’ at the bottom of my diagram. But what if people want a text generation engine they can use in a Unity project, or an iOS app with a completely different interface paradigm?

So, then, a number of calamities.

This last part of my talk is a secret history of the last three years, and what I’ve been working on to address these issues.

Step 1 was to adapt inweb, the literate programming tool used for Inform, so that it could break projects up into modules. I then began moving the lowest-level code from inform7 into a module called ‘foundation’: memory management, filenames and pathnames, dealing with the command line, string handling, HTML and Javascript, making EPUB books, and so on. In the process, I abolished all use of C-style strings, migrated to wchar_t characters, and removed all fixed-sized arrays.

Step 2. All of the outlying Inform command-line tools were rewritten as inweb projects using this common foundation module. The complete suite is now as shown. inform6 is off to the side because it’s a separately written open-source tool: I haven’t altered it and don’t for the moment intend to.

‘intest’, which started as a hacky tool for running test cases through Inform, is worth mentioning as a tool which has been completely rewritten. It’s now quite a capable tool for testing any command-line app with broadly textual output: a mini-language enables the user to set up and automate batches of tests, spread them across processors, collate the results, and so on. I’ve used this to define test cases for all of the tools above.

As this little screenshot from the Terminal shows, the whole Inform infrastructure now works fine at the command-line, and doesn’t need a whole lot of other software already installed before you can use it (Perl, for example).

Step 3 was to further subdivided inform7 into modules, as shown here.

These modules have mutual dependencies, but it’s possible now to compile some of the input end of Inform on its own, which has potential for making hybrid compilers in future. For example, compiling just foundation plus words gives a program which reads in source text, breaks it into words, works out the vocabulary used and stores it all efficiently: you take it from there. Adding the syntax module lets you breaks down into sentences, identifying the verb, and so on. (This is in fact done in order to unit-test portions of the compiler when building Inform.)

Step 4 is probably the most significant thing I’ve done: ‘inter’. The new process for compiling a story with Inform is now one step longer, as this diagram shows. ‘inter’ is intermediate between I7 and I6. For efficiency’s sake, it can be compiled either as part of a larger program (so that it needn’t be launched as a process), or as a stand-alone tool. It takes as its input a new low-level but abstract definition of a story, and outputs Inform 6 code ready to pass along.

This abstract definition, called inter code, can exist either as bytecode in memory, or written out longhand in text, and the ‘inter’ tool can convert in both directions. Inter is quite readable in text form:

When compiling an Inform story in the GUI, all inter code normally exists only as bytecode in memory, for speed, but for example you could instead at the command line do something like this.

Why is this a good idea?

First, I6 code is fiddly to make, and I wanted to move that complexity out of the inform7 tool. Second, though inter currently generates I6 code, in future we might imagine it generating other languages — for example, C-sharp code for import into Unity, or even Javascript. This is a long way off, but at least is architecturally imaginable. Third, inter provides a basis for a form of linker, merging code compiled at different times: code made by inform7, or raw Inform 6 code, or code in the Inform template layer.

The design of ‘inter’ is motivated by that of LLVM, for any compiler enthusiasts here. Like LLVM, ‘inter’ has a pipeline architecture, configurable so that you can perform the transformations you want, in whatever order. This makes experimenting with new features easy: I can imagine people contributing peephole optimisation steps, for example. Two experiments I’ve made already are:

(i) Eliminating unnecessary code — for example, at present every story file contains code for sorting tables, whether or not any tables will ever be sorted. Removing that sort of thing appreciably reduces story file sizes.

(ii) Linking with a precompiled version of the Standard Rules — this is a tricky feature and I’m not sure it will be enabled in the next public release, but it does work on the 2000 or so test cases currently in place, and makes Inform run about twice as fast on them.

So where have I got to, as of today?

Well: there’s much more work to do on inter. What I’ve got does everything described above, but too much I6 generation still happens inside I7 and not inter. For example, a typical rule is generated to inter like this, with a huge wodge of I6 passed essentially verbatim.

This makes use of a necessary, if regrettable, feature of inter, allowing it to be passed raw I6 code in a ‘splat’. There was a similar feature at one time for values, called a ‘glob’: it was a milestone when inform7 no longer produced any globs, and it will be a bigger one when inform7 can do without splats.

Here’s inform7 producing rather better inter code:

As can be seen, inter, like all low-level languages, is verbose. It is designed to be written by other programs, not by people.

This major restructuring of Inform, which has taken three years to carry through, aims to address four of my five existential crises. It’s now making real progress, I think, and my plan is to make a public release later in 2018 which pushes some of this new code out to real users. If all goes well, they won’t notice the difference at all. That’s the life of the software developer.

All of that sounds like worthy software engineering, or I hope so. But how does it help with my fifth crisis: the need to make more flexible forms of interactive fiction, and to break away from command-line interfaces as the only paradigm?

Ultimately, it may actually help quite a lot, because of the (speculative, future) ability to translate inter into code which could be used in Unity projects.

But that is only one aspect. I believe that it’s time to make a decisive step into a rapidly-establishing world in which the object produced by IF is an app (Hadean Lands, 80 Days), or a website (Twine, Undum and so on), rather than a story file. Inform already has a tentative foot in this world, in that it can produce websites with embedded interpreters, and an Inform story file can be souped up with a lot of work into an app. We need to do more. The websites we can make are too limited, and the apps too hard to make. At the same time, we need to embrace a diversity of possible user interfaces: pure command parsing; button or other gadget-enhanced command parsing; choice-based systems with touchable buttons; hypertextual choice interfaces. In doing

all of that, we need to provide the authors of such essentially choice-based IF with the right kind of world modelling. What we have now, certainly, but also more flexibility and ease in setting up plot structures and dialogue. I see all of these things as complementary.

Work on this has really got no further than speculative design documents, but my idea broadly is to unify different UI paradigms by regarding a story as a sequence of choices, in between which text is produced. (In some stories, having taken no action when some real-time timer runs out may itself be a choice.) Each choice results in either (a) an action, or multiple actions; or (b) a scene transition.

Let’s look at what Inform might be like to write, for different UIs.

— Using the command parser UI, the player makes a choice by typing a command, and the result is an action. That’s what we have now, of course.

— Using a touch-based UI, the source text will need to define what options are available at any given time.

The UI would then, in some way, offer touchable buttons for whatever options are available.

— Using a hypertext UI, the author would instead write something like:

At the normal point where a command-parser IF would produce the prompt and wait for the keyboard command, a hypertext IF would simply wait for the player to click one of the links currently exposed on screen.

This is only the barest outline, but the general aim is to provide for simplified and more flexible user interfaces, but retain the full strength of Inform for modelling a background world and generating text. Most of the hard work in web programming terms would be done by Vorple, a powerful set of Inform extensions by Juhana Leinonen, who is here tonight. Vorple already allows for a wide range of effects. And we want to make it possible to produce not only interactive websites but also beautiful ones out of the box, with some of the typographical magic which made Ian Millington’s undum, or Inkle’s Eighty Days, such an experience. Lastly, and in keeping with where Inform came in, we need to make everything almost transparently easy for the aspiring author.

So that is where Inform is. You will see that as this talk has gone on, I’ve slid more and more into the future tense — into things it doesn’t do yet, but which I want it to. That’s as it should be. The goal of software like Inform is to make a little contribution to culture, and culture is always something moving and changing, as artists innovate. Software that isn’t changing and developing leaves the scene because it doesn’t keep up with the creativity of its users. So Inform must change, and must develop. It’s a work in progress.