Live22Paper<br>Ampleforth: A Live Literate Editor

Abstract

Ampleforth is an editor for rich text documents with embedded media, including arbitrary interactive user interface elements.<br>These may themselves be transcluded Ampleforth documents.<br>Ampleforth documents are Newspeak objects and therefore naturally have a dynamic scope which can be used to reference live objects within them.<br>Documents then mesh naturally with exemplar support in the IDE, making it easy to write code in the scope of the document and evaluate it live at any point.<br>A document contains a markup program that runs in the document's scope. Executing the markup subsumes the concept of weaving a literate program.<br>The structured view of code provided by a Smalltalk-style IDE likewise subsumes tangling.

The system allows for either WYSIWYG or markup editing (or a mix of both), and maintains a live bidirectional relation between the two.<br>Ampleforth runs in the web browser, and has the potential to replace a wide variety of editing tools such as word processors, presentation managers, GUI builders, computational notebooks and more.<br>The editor is written in the Newspeak programming language, and incorporates a complete Newspeak IDE, enabling Ampleforth to be scripted and modified live within itself.<br>We discuss Ampleforth's design, implementation and use. We believe<br>the design principles of Ampleforth extend beyond documents to much<br>more general virtual worlds.

Introduction

Let's begin by recapping what live literate programming means.

Live programming means that when you change a program,<br>you instantly see the consequent changes to its behavior.

To illustrate this, consider the trivial counter application shown<br>below:

The counter is live; try it out.<br>You can use the increment button to increment the counter,<br>the decrement button to decrement it, and reset to set it back to its initial value.<br>Leave the counter at a non-zero value. This will be useful later.

Suppose you decide that the word reset isn't clear.<br>You'd like the reset button's label to be more explicit - perhaps it should<br>say set to 0.

The code that controls the counter display is in the method<br>definition below. Click the toggle arrow below left to open the<br>method:

definition = (<br>^row: {label: subject count. mediumBlank. button: 'increment'<br>action: [ updateGUI: [ subject increment ] ]. button: 'decrement'<br>action: [ updateGUI: [ subject decrement ] ]. button: 'reset'<br>action: [ updateGUI: [ subject clear ] ]. }

Change the line that determines the reset button's label<br>(it's just above the closing curly brace, } ) to read:

button: 'set to 0' action: [updateGUI: [subject clear]].

and accept the change.

The displayed counter has changed as desired.<br>Moreover, the state of the counter is preserved - its value is as you left it before you changed the program;<br>we did not restart the counter program, or refresh the web page.<br>This is crucial. The counter state may be trivial, but in any real application,<br>recreating the program state is difficult, tedious, time consuming and error prone.

Literate programming means writing programs as essays: a well structured narrative,<br>designed for human consumption, well presented both logically and physically.

Live literate programming combines live and literate programming into something greater than the sum of its parts.<br>You should be able to write programs as essays, if you so desire, but you should also be free to write them as<br>slide presentations or interactive demonstrations or perhaps something else entirely. And you should<br>be able to write multiple narratives about the program, or about several programs. And they should all be live.

This essay is an example of live literate programming used to discuss<br>itself, but there is more to it. Once you have a tool adequate to the<br>task of live literate programming, you find you have much more. You<br>have an editor for interactive documents of many<br>kinds.

Design Principles

The core requirements for the editor are:

It must allow the creation, modification and viewing of hypermedia documents with interactive content.

It must be fully programmable.

It must specify documents linguistically.

(1) is obvious. However (2) is deeper than might appear.<br>It means that everything the editor can do in response to the UI can not only be done, but also modified, programmatically, by the user of the editor.<br>Hence it isn't enough that the editor support scripting of its operations.<br>It must be implemented in a fully dynamic language, so that one can modify the running editor from within itself.<br>Conceptual economy tells us that this programming language should serve as the scripting language as well.<br>Lastly, (3) implies that the document is defined by a language, which most naturally would be a markup language.<br>The markup is the document representation, and is reified in the editor's implementation language, which is also its scripting language.<br>A linguistic definition of the document is easier for humans to...