Text-Graphic Pattern Notation

To conclude this section, mention should be made of the other way PAM functions can be denoted visually. As mentioned, the notation used here for representing PAM functions on text-graphic objects is derived from McCarthy's "blackboard notation" for LISP functions on symbolic expressions (McCarthy and Talcott [10]). In addition (again following McCarthy) there is also an alternative reflexive notation in which PAM function calls themselves are represented by text-graphic patterns, e.g.

and

This more basic notation allows PAM function calls, as text-graphic patterns with explicit tree structure, to be conveniently manipulated either manually (by the human using handPAM) or programmatically (by other PAM functions). And, for practicality, the more basic notation was implemented first when it came time to actually evaluate visual objects on the screen, as can be seen from the illustrations in the next two sections.

Speaking of implementation, the relationship between LISP and writtenPAM in the current system should be made clear. All the primitive PAM functions are simply LISP functions which take a particular type of LISP objects as arguments and return that same type of LISP object which can then be displayed by the display processor addToScreen. Thus the actual code is LISP, using the PAM names like first and rest so that car and cdr still work, and adding question marks for predicates so that the PAM equal? is distinguised from LISP equal. For example, shown below is the code for treverse, which reverses the top level tree structure of a pattern (but not its spatial structure); and the code for lisptoGraphicTextTran, which translates LISP sexprs into visual patterns having the same tree structure as the sexpr, but with a graphic text object for each textual LISP atom. First in blackboard notation:

Here the global variable nilpat is bound to the empty visual pattern; and the function makeGraphicText returns visual vector characters for LISP characters. These two points are important in that they have been overlooked in subsequent function definitions for purposes of clarity/brevity. The blackboard notation assumes an interpreter which supports visual literals like and instead of using nilpat and makeGraphicText[ ].