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 ). Thanks to the
simplicity and power of LISP functions and structures, some of the ambiguities of text-graphic manipulators
(Sutherland , Futrelle ) are clarified, in particular the one characterized by Sutherland as the Structure of
Drawings Problem. handPAM is described in more detail in Lakin , . 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:
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 ) 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
(computer medium for working group graphics
) and a processing
(visual grammars for visual languages
, a visual agent for performance graphics
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