CWTGF: Introduction

Introduction

In order to set the stage for writtenPAM, the subject of this paper, a bit of background needs to be given on handPAM, the manual environment in which evaluation occurs. The PAM system as a whole was designed for the agile manipulation of text-graphic patterns      first manually, and then, later, programmatically. The viewing screen for handPAM offers a static display (it doesn't scroll) with discretionary evaluation (objects first are created simply as visual entities, and then later submitted for evaluation). Objects on the display follow LISP structure      either atomic or tree structured. This structure for text-graphic images was chosen because it most directly satisfied the needs of manual manipulation.

Initially concerned with manual manipulation, the user soon finds that the selective creation, moving and erasing of text-graphic objects necessitates some way of structuring complex objects and their parts; trees provide a simple and obvious way to structure visual objects, e.g.

 
 
Complex objects with such a tree structure are called text-graphic patterns. handPAM is defined by a function called handle, and is actually a generalization of Warren Teitelman's LISP editor to text-graphic patterns on a static display (Teitelman credits Peter Deutsch for the original idea of a structure editor [6]). Thanks to the simplicity and power of LISP functions and structures, some of the ambiguities of text-graphic manipulators (Sutherland [1], Futrelle [2]) are clarified, in particular the one characterized by Sutherland as the Structure of Drawings Problem. handPAM is described in more detail in Lakin [7], [11]. Among the editor operations available on the "current form" is evaluation, thus permitting writtenPAM forms to be created and evaluated from within the handPAM environment.

writtenPAM allows people to talk directly about text-graphic objects and manipulations on them, as for example in setting the value of variables:

 
 

constructing patterns:

 
 

taking them apart:

 
 

and making equality tests:

 
 
In short, writtenPAM's functions and predicates operate on visual objects and return them as values. As a matter of fact, this language is ‘intrinsically graphic’ (Futrelle's term [2]) and only later textual, but we still speak of writing programs, so we call it writtenPAM for convenience.

The remainder of this paper deals with writtenPAM. In particular are examined data types and structures (Figure 1), basic functions and prediates, examples of pattern processing, and examples of pattern evaluating.



So, why do this? Why generalize lisp to handle text-graphic forms? Short answer: because graphics need to be first-class computational objects! Long answer: because then we have the right tool to create a visual instrument for generating text-and-graphics in real-time. The resulting system is both a performing instrument (computer medium for working group graphics) and a processing instrument (visual grammars for visual languages, a visual agent for performance graphics). Put another way, as already mentioned, then interactive text-graphic engines can then be defined, allowing text editors, text-graphic editors (for document preparation), circuit design aids, and visual language interpretors to all be developed in the same LISP-like environment. Where graphics are first-class objects.