(‘o\ll’Lw1:l~ (:RAI’III(:~ .ATIl Ihl-\(:E I’KocESSIN(: (1972) 1, (317-3401

EX.GRAF: An Extensible Language Including

Graphical Operations*

This paper describes a high-level extensible language. The language allows the user to define new data types and new operations to suit his needs and to simplify sul~sr- quent programming. This work began as an effort to produce a “graphic language,” but soon led to the design of a general purpose extensible language in which graphical data types and operations could easily be embedded.

A prime aim in the definition of the language was to provide powerful features at a level that is easily understood and yet is straightforward to implement. Examples fol computer graphics are given to illustrate the most important features of the language.

1. INTRODUCTION

High-level language facilities are needed to simplify many different pro- gramming problems. This is certainly the case with applications involving computer graphics in which many data representations, including numerical parameters, topological data, relational data and graphical information, may exist in complex data structures. Therefore it is necessary to consider the problems of specifying the representation and internal processing of all forms of data, with graphical data as one special case, when discussing gen- eral purpose languages.

The prime requirement of a general purpose language is to have a sufficient set of data types and operations on these data types to permit efficient and elegant programming for the given application. However, it is not known or agreed upon, as to which data types and operations form a sufficient set even for one class of applications, e.g., graphical. Some data types, like PTR (pointer or reference) seem to be fairly obvious, but the operations one would like to perform on variables with type PTR are not so clear. Operations on graphical display structures are even less clear. Therefore the language that is being developed is an extensible language. In this language new data

* This work waj supported in part hy the Air Force Office of Scientific Research, Air Force Systems Command, USAF, under grant AF-AFOSR-70-1854, Professor H. Freeman, Principal Investigator, and in part by a National Science Foundation Institutional Grant to New York Cniversity.

f T. J. Watson Research Center, IBM, Yorktown Heights, New York; formerly at New York University.

t Research Institute for Automation, Hungarian Academy of Science, Budapest, Hungary-. Visiting scholar at New York University, July 72-September 72.

317

318 WILLIAMS ANI) KHAMMEH

types and operations that are considered to be use&l for a given application can be added easily by anyone at any time. The important point is to JXO”- vide the means for the user to create new data types and operations. This i$; different from the work of Smith [13]. Smith extended PL/I to GPL/ 1 by I I). eluding two new data types and several new operations. The new data tcpf~4 are tjector and image, where vector is a point having two or three coordinate values, and image is a variable having values that are “combinations of ~jic- torial data, pictorial function values and other images,” and “imagc~ data consists of points (vectors), text or values returned from image t;mctiruls” 1131. He also defined vector addition, subtraction, scalar and cross prodrxct operations for vectors, and transformations (i.e., position, scale, and rotation), inclusion and connection operations for images. Also, the Phil interrupt facility is extended to allow interrupts from graphical accessories at~tl tht~m~ is a special ANIMATE statement for animation purposes. This approach appears to be a step in the right direction hut it provides a fixed set of’cluta types and operations. In the language described in this paper, the user i> encouraged to develop his own data types and operations as he discovcyr\ ,i need for them.

We acknowledge immediately that such languages exist already. The mosi important of these, in our opinion, are ALGOL ‘68 [4,17] and ELI i&w Wctg-

breit) [15,16]. ALGOL ‘68 is somewhat difficult to lmderstand and list3 ;mrf has not been implemented very widely. ELI is more easily understood ancl our work has been considerably influenced lay it. ELI is more ambitious thall our efforts, but our aims are different. Our aims are to define an extensibls, language that is simply understood by the user and that is not overly difficult to implement, and which is also specifically useful for graphical applicatiotrh. It would be interesting and helpful to experiment with different graphical data types and structures and attempt to find the most useful data types ant1 operations for a wide range of graphical applications.

2. THE LANGUAGE

A program in the language is a sequence of statements. These statemetrtx may define new types of objects, new elements of a given type or may per- form calculations with the previously defined elements. The nlost impor”-. tant feature of the language is the possibility to define new types and opera-~ tions between elements of new types. This then allows expressions to I)(> built in other high level languages.

In this section we describe the main features of the language. The RNI;’ syntax for the statements that follow is given in the Appendix.

2.1 The Definition of‘ New Types

The language has a few built-in basic types which are widely used in eom- puting: REAL, INT, (integer) BIT, and CHAR (character). Variables having these data types can be used in expressions and assignment skatcmcxrlts ,;:s,. in other languages.

In most applications there are some &sic> a)l,iec:ts ~haracterlmc~ /I> ,i ,I< ‘1

EX.GRAF 319

of structured data blocks and it is necessary to perform some well-defined operations on these blocks. The statement STYPE (read S TYPE, which stands for Structured TYPE) is used in the language to specify names of a new type and also to define the structure of the elements of this type in terms of previously defined element types. The built-in types behave like any other previously defined type in this respect.

A new type is defined by assigning a name to the type and specifying its constituent subparts. Each subpart has a name, possibly dimensioned, and a type specification, which must be an existing type, i.e., either a built-in type or a previously-defined STYPE.

EXAMPLES. STYPE RINGC: (NEXT: PTR, LAST: PTR, DATA: INT);

STYPE ABLK: (HEAD: INT=8192, BODY(40): INT, NEXT: PTR,

DATA: PTR, TAIL: INT=l);

In the first example a block structure is defined to consist of a pointer, a sec- ond pointer and an integer, and the type of this structure is named RINGC. Subsequently, an element or object of type RINGC can be created with a DECL statement. The second example shows how initial data values (con- stants) may be assigned to a structure. Assigning values in STYPE statements is a very convenient method of placing values in every object of a given type and saves the user from the tedious task of specifying the values in every DECL statement that creates an object of this type.

The information given in an STYPE statement is stored in an STYPE record. The record contains the name of the new STYPE, its memory re- quirements for an element declared to have this STYPE, and a reference to the record which describes the structure of the first subpart. The subpart information is correspondingly similar and is stored in an SFORD record.

However the information about a subpart of an STYPE can only be ac- cessed via the STYPE information, Therefore type names used in subsequent declaration statements can only be STYPE names and not names of subparts. Similarly for reference purposes, as is explained in Section 2.3, a subpart name has no meaning by itself.

As it is possible to create new elements of any type at run-time the STYPE specifications are retained through compilation and become part of the run- time object program.

Some people have suggested different forms for this statement and for some of the following statements; APL, PL/l and others have been sug- gested. We happen to like the syntax we have chosen but we remain quite open to other suggestions. Some modifications have already been made as a result of such suggestions.

2.2 Declaration of Variables The DECL statement is used to define names as variables or arrays of a

given type and also to assign initial values if necessary.

EXAMPLES. DECL INDEX: INT; DECL VECTOR (10): REAL, MATRIX (40,401: TNT. DECL Bl: HLOK = (BLOK: 1526, (40:kO). 0):

The first example declares the variable INDEX as one of tllra t>rpi: 1W (integer). The : second csxample has two declarations in it: the first ctefiltc~~ .: vector with ten elements of type REAL, while the other defines a 40 b! 4l1 array of integers. The third example defines the name RI 34: a t,nriai)lc ati type BLOK which must have 1)ee11 defined previousl>. as tlrts Ilarrit’ o? !II’ STYPE. The variable 131 is given tllcb values of the constatlt f’oll<,cving lhc = sign; constants arc discussed in paragrapll 2.5. Oni! this 011ch partic3:IS;ti instance Bl of the type BLOK has this data vaiur.

A basic point with DECL and STYPE statements in this languagrh i, tll;i! they may occur not only at the beginning of a program or program mc~tlrnie but also later among other statements which are characterized 111 utht*r T,in- guages as “executable statements.” At any time during program c~xec~~t~r);rr it is possible to use a DECL statement to create new element:, oi ;I gi\c,:: type. At this time storage is assigned to the new element and a tleclaratic,l~ record is created for it. This record contains tire name, the storage addrehh, the array specifications, if any, and a reference to the STYPE; record wlkir*)r defines the type of the new element,

As shown in the Appendix, the syntax allows an ernpt), it&s chxprexsl!ii in parentheses in a declaration statement. This is used in routines wht~~: il formal parameter is specified to be an array, the size of which WII ortl?, /t:, determined when the routine is referenced. An example is given irk Sectl’i 14: 2.4. Also an array of elements can be defined with a11 index of zero, Consicit~a the following example:

DECL DFILE(W: INS’I’:

This means that DFILE is an array of‘ INS’I‘ t).pc elements, Ijut II(I uf)\>ah! limit is given for thca nlmibcr of elc~ments in the arm\‘. At an! time ilrcstt, 11 a given number h’ of elements in this array and the supporting rlxn-time, .>$. b/. tern will provide the appropriate access to these elements when DFILE ?(l properly indexed. A new element can be added to the array by the statcmt:tlt*,

INCR(DFILE, 1 j” DFILE -t II;

where rz is the name of a new element of type INST. The stateme~lt INC:!-i indicates to the system that the dimension of DFILE is to he increasc,tl ill one. For convenience this statement could be included in the definition o! the operation + with DFILE, then it is only necessary to write it OIIW. A complete example is given in Section 4.2.

2.3 Rclferencing Objects by Name

Names in the language are used as symbolic, referenc<,s and ~a\‘f’ri 91;~11\4

falls into one of the main name categories, type-tlame, varial)l~-ri;llxll,, ;,I:

EX.GRAF 321

The category of a given name can be decided always from the context in which a name is used; names used after a colon in DECL statements specify a type, names used before a colon in STYPE statements also specify a type.

Variable names are defined when used in “basic-decls” in DECL state- ments (see Appendix), and once defined they can be used in expressions for calculation purposes. The name of an object is used to reference the whole object, while subparts of structured objects can be referenced via name strings. Name strings are formed by concatenating with period delim- iters (.) the name of the whole object with the formal names of the subparts of that object. Any name in a string may be subscripted.

As an example, suppose that type CBL is defined as:

STYPE CBL: (HEAD; INT, BODY(40): INT, TAIL: INT);

and that 100 blocks of type CBL are created by the declaration

DECL TAB(lOO): CBL;

The tenth element of the BODY in the twenty-third TAB can be referenced by TAB(23).BODY(lO).

The references HEAD or BODY(lO) by themselves have no meaning, unless these names have been declared separately in a DECL statement to have a separate, quite different meaning. The reference TAB(23).BODY which can be used to reference the whole BODY within TAB(23), and TAB are also meaningful references. The exact meaning of an “incomplete” ref- erence like TAB is actually defined by the user, for, once a new type and elements of this type have been declared they can be used in expressions like any other variables.

An important point to note here is that whenever a name reference in an expression is evaluated both the object itself and its type are available so as to make it possible to decide which operation is to be performed. The defi- nition of an operation using new type elements is specified by a routine, as discussed in the next section.

2.4 Definition of Routines and New Operations

Operations can be defined for any types of operands. The operators can be unary operators or binary operators, they can involve lists of operands and they can occur in prefix notation or in infix notation. An EXPR statement followed by a block of code is used to define a new operation or a new rou- tine. An EXPR statement contains two operands and an operator. The oper- ator may be any convenient string of characters such as +, ADD, .3AD., etc. The triple “operand type, operator, operand type” uniquely identifies an operation. Thus the same operator symbol may be used unambiguously with different operand types to specify similar but different operations. An oper- ator priority code may also be specified.

EXAMPLES. (i) EXPR A+ B, 2;

BEGIN DECL A( ), B( ): REAL, N: INT;

322

N = SIZE(A); DECL C(N): REAL; For J- 1, N: C(J)=A(Jj?-B(J), RETURN C;

END: (ii) EXPR A = B, 0;

BEGIN DECL A, B: ABLK; A.HEAD = B.HEAD;

FOR J = 1,40: A.BODY( J) = B.BODY( J); A.NEXT = B.NEXT; A.DATA = B.DATA; A.TAIL = B.TAIL; RETURN A,

END; (iii) EXPR SPUR(A,iNI;

BEGIN DECL A(N,N), S: REAL N: IN’?‘: s =o.o; FOR J-1, N : S=S-+mA(J,J!: RETURN S;

END;

The first example above defines the addition for vectors as an operatior~ with priority 2. A and B are declared to be arrays without specified tlimkari sions. There is a run-time system routim SIZE, which can be used to fetcrh the current size of an element referenced by name. A statement OJ :I 191ot:i.

of statements has always a value which is the value last evaluated, or I’m;.’ plicitly referenced in a “RETURN” statement. The result of the opcaratlr,ri the address and type of C, are returned.

The second example defines the operator “==” for elements ot tlrpe ABLL. Note that = is an infix operator with two operands and has the lowest pr>>,’ sible priority. In this language, assignment statements are expressions. Al\cl any operator, including =, may effect one of its operands and change its v;li~~~~

The third example is a “traditional” subroutine definition which ~:al~*~~- lates the sum of the diagonal elements in ali array-.

The use of routines defined in the above way ih simply a means lor defirr ing the operator with given types of operands. In some cases this is similat to the use of procedures in ALGOL 60, or functions in FORTRAIK. If thaw operator is used in connection with basic types the operation is performrd in a “normal” way, i.e., with in-line compiled code, but if the operands types are user-defined STYPES, the corresponding routine that defines tile operation with the given operand types is invoked to execute the operation In both cases an address and a type for each operand must be determinrd from the name strings of the operands before the operation can be performed.

The basic statement form used in programming is the expresslon ;tnti III EX.GRAF expressions includes value assignment statements. Operators CXI!

EX.GRAF 327

ture of T and the display format. A conversion routine to convert real or in- teger three-dimensional data into display format would have to be supplied as a run-time routine with the basic EX.GRAF system because of the hard- ware dependency. Once the mechanism for creating SCL is understood, it is a straightforward matter to create translation and rotation operations.

Now all the transformation parameters to be applied to one object can be specified in one statement. The ordering of the operators is determined by their left to right sequence or by the precedence order number assigned to the operation when it was defined. As an example, consider that three houses are to be displayed at three different positions and with different scale fac- tors on a piece of property. A basic house shape is created first. This is done by declaring an array of items having a 3D graphical format, and defining X, Y, Z end points for the lines defining the house shape. Pointers Hl, H2 and H3 are declared also. The house is scaled and positioned and added to the display buffer three times; Hl, H2, and H3 point to each copy of the data in the display buffer.

DECL H(20): G3D, Hl, H2, H3: PTR; H(1) = (G3D: MOVE, (x), (y), (2); H(2) = (G3D: DRAW, (x), (y), (2);

H(20) = (G3D: 0); Hl = H SCL 0.4 DISP -500, +lOO, 0; H2 = H SCL 0.5 DISP -500, -300, 0; H3 = H SCL 0.4 DISP 0, +lOO, 0, ROT 0, 90, 0;

It is pointed out that the graphical commands need only be created once, but that they may then be used over and over again in expressions to de- scribe graphical structures, as in the above example.

3.3.2 Hierarchical Graphical Structures

In hierarchical structures one wants to create new instances of existing objects together with parameters to apply to each new instance of an object. In the house example in Section 3.3.1, three distinct copies of house were created; however, one could define the element “house” and then create three instances of it as shown in Fig. 4.

One could write the same statements as those given in Section 3.3.1 but build the different structure by defining SCL and other graphical operations differently. For example, one could define the graphical operations to (i) request a block of storage from a storage allocator, (ii) insert the appropriate commands and parameters, (iii) add a call to the element involved (house, in this example) and link the block to the previous such block. The first block would be linked to a system-supplied, standard, starting header, and the run- time system of EX.GRAF would keep track of the last block added and the display can be turned on, or off, in either hierarchical or nonhierarchical systems by statements:

328

r--Girt (SYSTEM)

H3

END INDICATOR

SHOW(PIC:T): OFF(PTCT1;

This technique for creating hierarchical structures has then aclvantayc, /ii being compatible with nonhierarchical systems from the point of‘ t,,ic~i;l. ,?S the user, because the statements are the same. However, to develop, rrlcjl’<. levels of hierarchy (more complex structures! and to allow thtr ciispln’; iii~ data to be incorporated into other nongraphical data structures morn power: ful statements are needed. Considerations of’ general purpose rcqu~rcmt-~r~t~~ leads to a different method of specifying hierarchical structures that is II~YI<.;I more versatile. Why not let the user create the storage blocks for tht, tmriv- formation parameters and allow him the possibility of storing any type 01 data in these blocks? After all, the graphical description of an objet-t is cjni? one attribute of the object.

To enable the programmer to create graphical commands and their parari+ eters in EX.GRAF, the following additional data types are needed:

GRV a graphical command and an argument value, possibly empty: GRA a graphical command and an argument address; GRIN a graphical command an indirect argument address; GOP any of the above, deferred until a value is specified at rlln-time.

These graphical data types can be used in the usual way, for example:

STYPE GBLB: (GI(6): GRV, LINK(2): GRA); DECL Pl, P2, P3: GBL2;

These two statements first define a data type that consists of eight graphicat items, six of type GRV and two of type GRA and then creates three variabl~~s having this type. An assignment statement to set the code andargument vali~r, is then expressed by:

P 1. GI(5) = (GRV: SCI,, 0.<5).

EX.GRAF 323

be used as unary or binary operators, but whenever an operator is used in a particular context, i.e. with given operand types, it must have already been defined in that context either as a built-in operation or by a previous routine definition. This also holds for operators in a complex expression consisting of many elementary expressions; each expression evaluation must yield a result, the type of which is correct for the next operation.

Constants in this language are either basic constants (integer, real, Boolean, character) or they are “structured constants” having a user-defined type. Structured constants contain basic constants grouped appropriately by paren- theses. A complete structured constant is enclosed in parentheses together with its type name. For example,

(COMPLEX: 3.52, 6.48)

Constants are stored according to their type and are used as parameters by passing their address and type.

:3. EXTENSIONS FOR GRAPHICAL APPLICATIONS

3.1. Gruphical Considerations

c\n important aim of the development of EX.GRAF is, as the name implies, to provide language features that are useful for programming in graphical applications. Graphical display equipment is rather specialized and has certain hardware peculiarities. To display a picture on a display screen, a display file containing a complete description of the picture to be displayed must be created. Often the description may be simply a list of the end-point coordinates of the lines that make up a line-drawing; but this coordinate data must be specially formatted for the display hardware. Also, in many display systems it is possible to turn light-pens on and off, select different display screens and perform other such control functions. These control functions can be specified by creating special bit patterns in words in the display file and may be hardware dependent as well.

In most applications it frequently happens that a small line-drawing will occur many times in a larger line-drawing (e.g., a logic symbol in a logic- diagram or a beam in a framework) and it is convenient to be able to make such a line-drawing an element or primitice for constructing larger line- drawings. It then follows that one needs to specify the position, scale and angle of rotation of these elements. Therefore, either gruphical c0mmand.s and parameter values, such as SCALE 0.3, must be included in the display file or separate copies of each instance of an element must be created in a display list. For example, consider the display structure shown in Fig. 1. We wish to have two copies of the line-drawing Tl but at different horizontal positions on the screen. Therefore, we could define a command DX having one argument specifying a displacement of all subsequent coordinates in the X direction and write the sequence of graphical commands shown in Fig. l(a). These commands mean set up a horizontal shift parameter 0.5, display Tl with respect to it, set up another horizontal shift parameter 0.3 and display 7’1 again but with respect to the new parameter value. If the

324

: i TI MOVE x y L

DX 0.5 DRAW x y :

TI DRAW x y z

DX 0.3 DRAW x y I

TI 0 j; i\

: ; \ :

(a) ‘l J

(b)

MOVE xi y L

DRAW x’ y I DRAW x’ y L

DRAW x’ y I MOVE x” y z DRAW xi’ y z

DRAW x” y z

DRAW x” y L

1st INSTANCE OF Tl i : (MODIFIED x VALUES)

i

2nd INSTANCE OF TI

* (MODIFIED x VALUES) ;

i

hardware can only execute move and draw commands then a &wart* [)a’~- gram must process these commands and build a display list from the int(lE mation as shown in Fig. l(c). Two sets of coordinate data with modified X values are created, one for each instance of Tl, and the display is maintaillcc! by the hardware display processor from this list.

Alternatively, the command structure shown in Fig. l(a) and (b) can irr~ stored and the commands can he processed by software so that actual CX)OL‘~. dinate values can be calculated and passed to the display. This can IW a i~ie computational burden for nontrivial line-drawings since the coordinate dat;) is regenerated for every frame of the display. However, if there exists ;i hard ware transformation array in the display processor the computational bdc 11 is considerably reduced because parameters of graphical (transformatioIi 1 commands can be placed in the transformation array and all data passing through the array will be transformed “on the fly,” as illustrated in Fig. 3. Thus the two different transformations of Tl can he represented directly, I)\

COORDINATE TRANSFORMED TRANSFORMATION coo~TANp;TE~ DISPLAY

) (x’,y ‘,z’)

TRANSFORMATION PARAMETERS

EX.GRAF 325

the structures in Fig. l(a) and (b), and requires only one copy of Tl, together with the different transformation parameters for each instance of Tl.

In this case for nontrivial graphical elements the display system is clearly more efficient than a display system based entirely on software. Further- more, it is possible to compute transformations of coordinate data relutice to another transformation. Moreover, if a set of transformation parameters can be saved and later restored, then any line-drawing can be made a sub- part of a larger line-drawing, or, put the other way around, it is possible to form new graphical elements consisting of instances of other elements. Therefore, complex hierarchically structured line-drawings, can be created; this is similar to the idea of creating complex program structures with many subprogram levels.

More details about graphical display structures can be found in Ref. [18] and the references cited therein. The purpose of EX.GRAF is to help the programmer build and manipulate complex structures (display andotherwise). The next sections deal with the specification of graphical data, graphical commands and the building of complex structures, together with examples.

3.2 Coordinate Data in Graphical Formats

The formats for specifying coordinate data in display files are machine dependent and so there arises the problem of creating values having these formats. One solution to the problem would be to provide a mechanism in the language for specifying word structures in terms of the bits in a word. However, such low-level specifications only need to be defined once be- cause all other users of a given machine need these same formats. Hence, it is better to include the necessary basic graphical types (formats) in the language directly, for a particular machine. For other machines correspond- ing basic graphical types would be provided so that the programmer need not know the difference. As a specific example, the basic word structures for storing coordinate data in display files for an Adage-AGT-30 computer (the graphics) system used by one of the authors (RW) at New York Univer- sity) are as shown in Fig. 3.

X, Y and Z are coordinate values, D is a move/draw flag, E is an end-of-list flag and MOVE/DRAW also specifies move, draw or end-of-list.’ If these types are built-in, then using the ordinary language facilities one can con- struct tables having elements of these types. For example,

STYPE GBLl: (HEAD: PTR, T3D1(30): G3D, TAIL: PTR); DECL TABLl: GBLI;

These statements create a block for storing 3-dimensional display format data, together with two link pointers. A reference to the Y value of the sev- enth coordinate in this block is then specified in the usual way by

TABLl . T3D1(7) . Y

’ Move means move the display indicator invisibly to the specified X, Y, Z coordinate posi- tion; draw means draw a straight line from the previous X, Y, Z position to the specified X, Y, Z position.

326

FOR THREE DIMENSIONS: ’ 14 15 29 BIT #

MOVE/DRAW z TYPE - NAME- G3D

X Y

FOR TWO DIMENSIONS: 0 13 14 I.5 2829 RIT#

TYPE-NAME. GZD 1

X E Y D

I~‘I(:. 3. Format for coordinate data in wn Adage display filv

In graphical applications it is very desirable to work interactively with the computer to input line drawings or arbitrary curves and quite often it i.~ not possible to specify in advance the number of coordinate points iri tlrt’ line drawing or curve. The user should not have to worry about this problr~, Therefore, in EX.GRAF, the user can dimension a table with zero dimerr-, sions so that the actual length of the table is left indefinite, and may be alter-thcl dynamically to store the appropriate amount of data.

3.3.1 Nonhierarchical Systems

Graphical commands and operations can be defined in the same WC+>’ <t:, numerical operations using the EXPR statement, For example, a scaltb corn- mand SCL to operate on a table of coordinate data can be defined by.

EXPR T SCL N ; BEGIN DECL T( i : G3D, N: REAL. M: INT, BUFPTR: WH:

M = SIZE(T); BUFPTR = BUFF(M); FOR J = 1, M: BEGIN K =J + BUFPTR;

BUFFER(K) = T(J) i’ N: END;

RETURN BUFPTR; END;

BUFF is a run-time system routine that reserves the next M availabl~~ locations in the display buffer BUFFER, and returns the starting position BUFPTR. An example of a statement using this operation is:

T2 = Tl SCL 0.5;

This statement causes a copy of Tl scaled to half-size to be added to thy di+ play buffer. The name T2 would have a value which is a pointer to the scaled coordinate data in the buffer, hence the data for T2 can always be found. It should be noticed that this definition of SCL as a graphical operator, or corn- mand, relies on other operations having already been defined. The multipli- cation T(J) *N is a multiplication of a three-dimensional value T( J, I>:, a r~! N, and requires its own EXPR definition. Also, the copy operation f-i in !ii+. same expression means put the result in the display buffer and rrlust a/~ be defined. The precise definitions in each c’ase depend on thca initial ctrrr#

EX.GRAF 329

This statement defines the fifth field of GI in Pl to be the graphical com- mand SCL with a parameter 0.5; it simply means assign a code for SCL and a value of 0.5, subsequently to be processed by a display processor program as discussed in Section 3.1. Both the command SCL and the parameter 0.5 are treated as data. If the type GOP, graphical operator, were used instead of GRV in the above STYPE statement, the specification of the graphical data type would be deferred until run-time which can he useful, and then any of the following assignment statements are valid:

Pl. GI(5) = (GRV: SCL, 0.5); for type GRV Pl. GI(5) = (GRA: SCL, A); for type GRA where A is a variable Pl. GI(5) = (GRIN: SCL, REFl); for type GRIN where REFl is a

pointer.

When no argument is required, the following form can be used:

Pl. GI(6) = (GRV: SAVT, 0);

SAVT means save the current transformation parameters so that they can be restored later by REST.

A more complicated example is the following:

STYPE INST: (PTRT: PTR, SAVE: GRV= (GRV: SAVT, 0), POSX, POSY, POSZ: GRV, CALl: GRA, CAL2: GRA = (GRA: 3DT, CROSS), RES: GRV = (GRV: REST, 0), LINK: GRA, DPTR: PTR);

This statement defines a structure that consists of:

. a pointer 1 a graphical command (with a value SAVT and parameter 0) . three graphical commands (for defining position parameters) . two graphical commands (for pointing to other graphical structures, the

second of which always points to CROSS) . a graphical command (with a value REST) . a graphical command (for pointing to another graphical structure) . and a pointer.

Then the following statement creates a variable 11 of type INST

DECL II: INST;

11 already contains the graphical commands SAVT, a call to CROSS and REST. Other values can be defined; for example, a displacement of 500 units in the x direction for the graphical elements called by 11 is defined by:

Il.POSX = (GRV: DX, 500);

where DX is a command meaning displace in the x direction. The type INST is used in a realistic example in Section 4.

Many graphics systems already have a display program for processing hierarchical display structures. The existing commands can he incorporated

330 WILLIAMS AN11 KKAMMEH

into EX.GRAF (since they are merely data in EX.GRAF) so that f1111 ~‘(rrn- patibility can be achieved with current display software. It should only 1~ necessary to supply a table of the command mnemonics and the corresprmtI~- ing code values and to perform a one-to-one translation of graphical <~)iir- mands when they are assigned as values of graphical data types. ‘Therh Ihc existing display program can be used for display purposes, and if therch j,l a hardware transformation array or other special hardware, advairtagr, (:i’ these extra hardware facilities will be taken automatically since c-un\rira~: display programs will undoubtedly already be using them.

It has been shown that with EX.GRAF the user can build striicturrci drz I play files or simple display lists, according to his needs. The display strrrcb~ ture can be integrated into an incore structure within the application strrrc”- ture or it can be a separate display list, possilile in a special buffer, togrsth~r, with correlation tables; depending upon the hardware available the user CY~XI create whatever structure he wishes and is aided in doing so. Clearly- tlst‘ aim is different from that of Newman /lo]. Newman’s aim was to eliminatr~ the structured display file; it could be that given appropriate hardwart~., !l~(% user might prefer to build highly structured display files.

Many new operations can be defined to operate on the graphica data vaIir~< (both on the coordinate values and on other display-file para~nt~te~~s), and .~14t+

on the graphical structures. Arithmetic operations can be specified for cl~:i play-formatted coordinate values, for testing the equality of coordinates., loo adding points to tables, for combining tables, and for deleting objects iblocbku in a memory structure) seen by a light pen or other indicating tirvir’e. .~ZYV I operations on vector strings could be defined as operations oii crltaratrt~~~ strings often are, to allow insertion, deletion and rearrangement of thf, t f~f...

tors. Operations to return the angle between two lines or to test for parallcL ism, inclusion, connectedness and overlapping can be defined. Indeed ant? useful operation limited only by the imagination of the user and the f:oir~- plexity of the routine needed to carry out the operation can be created aiicI subsequently used in expressions in EX.GRAF.

4. A!i .AlR TRAFFIC: DISPLAY ESAMPLE

AS a more real nontrivial, but also not too complicated example iising thic, language, consider the following,

It is desired to display the positions and some data for aircraft withiri ;.I three-dimensional volume about a control tower. The volume is called the view space. An aircraft is represented by a three-dimensional maltese croxh called CROSS. Each aircraft is represented by an instance of CROSS appr<,- priately positioned, together with a data-record (nondisplay) and a block ot text for display by the CROSS as shown in Fig. 5.

There are four different block types needed for the display; these are shou 1)

EX.GRAF 331

TABLE I

Graphical C ommand Mnemonics

~rransfonn~fyinS (alters current relative transform for subsequent display definitions) -__ JMP simple jump (branch) in display file RX, RY, RZ rotate about X, Y or Z axis DX, DY, DZ shift in direction X, Y or Z SCL scale in X, Y and Z

&n tr_sl TMG

SAVT REST CHR 3DT JMP ENDTXT NULL

call to a lower-level display structure, using the current transform as a reference save the current transform restore the last saved transform call to a character string(s) call to a table of coordinate data simple jump (branch) in display file end of text indicator do nothing, continue

-

in Fig. 6.2 DFILE is a list of instance blocks, each of which represents an instance of an aircraft as shown in Fig. 7. Each instance block contains trans- formation parameters, a call to a text block for displaying text and a call to the cross symbol representing the aircraft. The displacement parameters in the instance block specify the relative position of the displayed cross and text. Each instance block also points to the (program) data record for the air- craft and to an entry in a table called PTABLE that is used to keep track of all aircraft in the vicinity of the control tower. Each entry in PTABLE con- sists of an aircraft identification code and a pointer to the corresponding instance block.

When a new aircraft appears in the view space, an instance block is created and added to the display file (DFILE) and textual information extracted from the (program) data record for the aircraft is displayed together with a new

* EA51

* EW 501

* PA23

* TWIZ

* u23

* E47

VI<:. 5. Display of aircraft. There would be other text below each aircraft.

(01

MOVE (z) (x) (Y )

DRAW (2) (x) (Y)

0

(b)

END

PTABLE .v

--*CROSS DISPLAY

EE’ FoR AIRCRAFT

~1- DISPLAY TEXT FOR A SECOND AIRCRAFT

DATA - ~.~~ RECORD FOR A SECOND i CROSS: AIRCRAFT AIRCRAF7

mi

SYMBOL

. I - ~.. . . .

EX.GRAF 333

cross. When an aircraft leaves the view space its instance block is deleted but the corresponding data record is not necessarily deleted. For graphical purposes we are only concerned about aircraft in the view space.

4.2 The Example Program Statements

At the beginning of the program, block types are declared and the graph- ical commands for the maltese cross are put in a block:

STYPE SYMBOL: (S(7): G3D), VBLOCK: (COM(3): GRV, CAL: GRA = (GRA: NULL, 0), END:

GW, CHS : (C(6): CHAR), TBLOK : (NAME, POSX, POSY, POSZ, SPEED, DIRX, DIRY,

DIRZ: CHS, END: GRV = (GRV: ENDTXT, 0)); DECL VIEW: VBLOCK, CROSS: SYMBOL; STYPE INST: (PTRT: PTR, SAVE: GRV=(GRV: SAVT, 0),

POSX, POSY, POSZ: GRV, CALl: GRA, CALS: GRA = (GRA: 3DT, CROSS), RES : GRV =(GRV: REST, 0), LINK: GRA = (GRA: RET, 0), DPTR: PTR);

DECL DFILE(0): INST; CROSS.S(l) = (G3D: MOVE, (x), (y), (z));

CR&S.S(G) = (G3D: DRAW, (x), (y), (z)); CROSS.S(7) = 0;

The rotation parameters in the VIEW block are set to the values corre- sponding to the settings of three inputs (dials). These inputs are sampled once per display frame, and the sampled values are put into INl, IN2 and IN3.

VIEW.COM(l) == (GRV: RX, INl); VIEW.COM(2) = (GRV: RY, IN2); VIEW.COM(3) == (GRV: RZ, IN3);

All the above statements only need to be written and executed once to de- fine the basic building blocks for the data structure for this application. The following shows how operations can be defined using these blocks.

When a new aircraft enters the viewing space a record of data becomes available as the current record and new structure can be created.

DECL NEWT: TBLOK, NEWI: INST; NEWT.NAME =. . . NEWT.POSX=. . . data from incoming record.

NEWT.DIRZ =. . .

334 WILLIAMS AND KHAMMEH

NEWI.POSX = (GRV: DX, (x)); NEWIPOSY = (GRV: DY, (y)); NEWI.POSZ = (GRV: DZ, (z)); NEWI.CALl = (GRA: CHR, NEWT); NEWI.DPTR = (address of data record);

The new text block NEWT and the symbol CROSS are referenced ironi the new instance-of-an-aircraft block NEWI. Once properly, created tlrc NEW1 block has to be added to the DFILE in order to display tile aircraft symbol and its associated text, and an entry is made to PTABLE:

DFILE + NEWI; PTABLE -!- (NEWT, NEWI);

The operations must have been defined for these expressions, tar example- the operation + with DFILE could be defined as follows (note that the deli- nition includes the statement INCR which increases the dimension of DFIL,E by one as explained in Section 2.2):

EXPR AS-B; BEGIN DECL A( ), B: INST, N: INT: INCR(A, 1); N = SIZE(A); IF(N=l)

THEN VIEW.CAL = (GRA: IMG, A(l).SAVE) ELSE A(N-l).LINK = (GRA: JMP,A(N).SAVE);

RETURN A; END;

Deleting an aircraft from the viewspace is similar, the statements could l,c,:

DFILE - K: PTABL,E --- K;

and the first of these operations, for example, can be defined hy the follow .. ing code:

EXPR A-B; BEGIN DECL A( ): INST, N, B: INT; N = SIZE(A); IF(B > N)

THEN ERROR ELSE BEGIN DECR(A, 1);

N = N-l; IF(N=O)

THEN VIEW.CAL = (GRA: NULL, 0) ELSE IF (B=l) THEN VIEW.CAL = GRA: IMG, A(2), SAVE) ELSE IF (B=N) THEN A(B--I).LINK = (GRA: RET, 0)

EX. GRAF 335

ELSE A(B-l).LINK = (GRA: JMP, A(B+l).SAVE); FREE(A,B); END;

RETURN A; END;

DECR is a routine to decrease by 1 the size of A, which represents DFILE in this case, and FREE is a routine that returns the block B from array A to a free storage allocator. ERROR is an error routine which aborts the operation.

Clearly this is an oversimplified example; its only purpose is to show some aspects of the language. Any real application would involve many new oper- ations and would be too involved to be included here.

5. IMPLEMENTATION

It was pointed out earlier that one of the most important aims of our work was to develop a working system for graphical applications. An implemen- tation using an ADAGE AGT-30 that has a disk backing store, an advanced graphical display, and various peripheral devices has been started at New York University. The programming languages available are FORTRAN, GRAFX (a graphical display processor that processes hierarchical structures) and ADEPT (an assembly language).

It was decided to make use of the FORTRAN facilities3 because FORTRAN already has the necessary arithmetic capability, it avoids reinventing the “go to etc.” and also because program preparation and debugging is easier than in assembly language.

A preprocessor breaks down EX.GRAF statements into FORTRAN state- ments which are then compiled into machine language. A set of run-time routines are used in conjunction with the resulting code to execute the com- piled program. The run-time routines are being written first so that the lan- guage ideas can be tested by writing the FORTRAN calls that would be produced by the preprocessor. Then, if the success of the language warrants it, a compiler for EX.GRAF should be written to achieve a greater efficiency. A few examples are presented to explain how the overall system including the preprocessor will work.

In Section 3 the following statements were used: (i) STYPE GLBB: (GI(6): GRV, LINKS(2): GRA);

. . . (ii) DECL Pl: GBL2;

. . . (iii) Pl.GI(5) = (GRV: SCL, 0.5);

The first statement defines a new type, the preprocessor first outputs a call

CALL STYPE (‘GBLB’)

The name is passed as an Hollerith constant. After that there is a call state-

L PL/l would be much better, and there is a possibility that a PL/l compiler will become available.

ment for every part of GBL2, in this case there are two sulrparts, called “S-formal-D” in the syntax (see the Appendix).

CALL SFORD (‘GBLB’, ‘<:I’, ‘GRV’, 6, -- i, -~ i; CALL SFORD (‘GBLS’, ‘LINKS’. ‘GRA’, 2, 1, ~- I )

Finally the STYPE definition is ended by

CALL SFORD (‘GBLB’, I.), 0: 0, 0, 0)

The last three arguments in each case are dimension information, with ! signifying no dimension. These calls are compiled and executed in the osiiir/ way, thus executing the original STYPE statement.

The information supplied via these call statements is stored in the mem”” ory in the form of symbol tables which contain a separate eritry, or record, for each defined name. These entries contain information about the rt;mn* in the form of character strings, integer numbers and references to othtq, entries.

The STYPE subroutine adds the new type name to an STYPE tabIt,: and creates an STYPE record for GBLB. Subsequent calls of SFORD ctstablisl~ new SFORD records which are chained to the STYPE record in their c~rric~i of appearance in the STYPE statement. The SFORD statements may i;forc” up to three index limits (dimensions) and a reference to another type rca<:or~d defining the type of this subpart of GBLB. As the type of the subparts ofGBI2 are known at this time their sizes are known also, thus the total size ot’GBI,Z can be calculated. When the above DECL statement (ii) is read by the prt:,- processor, it outputs a call to the DECL routine identifying a name and typ<t and three index limits.

CALL DECL (‘Pl’, ‘GBLB’, --I, 1, --1)

The DECL routine creates a new DECL record with this information, and contains a pointer to the type of the element being declared. Note thitt at this time a search is made through the STYPE records for GBL2.

The next statement (iii) to be explained, is an “expression statement” 1)~. cause the = sign is an operator in this language. First the types of the twtr operands have to be determined in order to know which routine is needetl to carry out the operation. The variable reference on the left side is evaIn ated by:

CALL REF (0, ‘Pl’, --1. -1, -1) CALL REF (1, ‘GI’, 5, --- 1, -- 1)

The memory address and type of the evaluated reference are placed on top of two stacks ADDR and TYPE, for use by the system run-time routines.

On encountering the constant on the right of the equal sign a DECL state- ment is output first to assign storage to the constant and to set the address and type registers.

CALL DECL (0, ‘GRV’, --- I. --1, -I)

The following subroutine calls perform the data assignmeiit.

EX.GRAF 337

CALL DATA (1, SCL) CALL DATA (1, 0.5) CALL DATA (0, 0)

Also the type of the appropriate part is retrieved via the STYPE record for GRV and its chain of SFORD records. Date assignment for basic types is predefined in the system (as in FORTRAN).

At the end of preprocessing the constant, the address and type is stacked and a BINary Operator subroutine is called:

CALL BINOP (2, ‘=‘, 1)

The operator code is an Hollerith constant and the indices of the operands in the stack are the other parameters. This subroutine first determines the types of the operands, and then passes the address and type of the operands to the routine that executes the operation with the given type operands. Attempts to perform illegal operations or operations with incorrect types would cause error messages to be output.

The address and type of the result is again put into system stacks for use with subsequent operations, e.g., whenever compound expressions are broken down into subsequent operations. Partial results are stacked as in the usual processing of complex expressions.

These examples show the basic concepts used in the implementation of the system. Other features not discussed here, e.g., storage of routine defi- nitions, initial data definition, etc., can be implemented in a straightforward manner. It is obvious that complex source language statements are pre- processed into fairly long sequences of CALL statements. The advantages of having a preprocessor are that it relieves the user from the tedious burden of writing out all the call sequences and argument lists and thereby encour- ages him to think at a higher level and work more efficiently.

6. CONCLUSION

This paper presents the design ideas for a high-level graphical language. A language having the characteristics of the one presented here is needed for many difficult programming situations, particularly for applications in- volving computer graphics, to eliminate the need to use low-level, machine language programming. The basic concepts are to provide a means for cre- ating new data types and new operations with the new and existing data types. The main aims are to make the language easily extendable, to pro- vide a mechanism for dealing with graphical display files and data structures, but to keep the language fairly simple and straightforward so that implemen- tation is not too difficult. These are different aims from those of Smith (GPL/l) and Newman (EULER/G) and also from those of Wegbreit (ELl) and the designers of ALGOL 68.

To implement the language on different machines the definition of the basic graphical data types would have to be different, an appropriate soft- ware display processor would be required to run on the different hardware and a few run-time system and I/O routines would be needed. It appears

that if these requirements were satisfied, which is not difficult, one i~rrld write programs to run on a number of different machines that have difFvrcnt graphical consoles and accessories.

Also the language could be used on both a large computer anti the sn~aller- computer in computer satellite configurations, which are cornrnorrl>~ <‘ii), ployed in graphical applications.

The problem of memory management has not been tackled c%xplicrtl\,. One can say that it is a part of the implementation problem. IIowevt’r tl-xF’rc% is another possibility: the language could be developed further to allow tiw definition of page structures (for data). Although this additional burdtri ~)RI the user is undesirable, it might be necessary for the user to define data-page structures for particular applications to make efficient 11s~~ of the ~nerntrry of’ a small computer.

An important question that has not yet hs satisfactorily treated arid hence was omitted from this paper, is the specification of I-irig strwtuw.* and ring operations which are widely used in computer graphics. Of C”WIJW: the user can define the appropriate operations to create and manipulate rings with the language as it has been described, hut he would like LO ti-rirrk an d work on a still higher level. The problems are closely related to the stijr- age management problem mentioned above.

Once the implementation is completed, future ideas to be worked on usir~q the language as a tool are the specification of: (1) primitives and structrires for describing motion in animation, ~2) data types and structures for apIrli(~. tions involving quadric surfaces, and (3) data types and operations for trrlag;h processing.

i4E’I’E<NI)IX

Syntax for the statements described in Section 8: (Statement) : : = (EX.GRAF-statement) / (FORTRAN-statemeriti (EX.GRAF-statement): : == (STYPE-statement) j !DECI,-statc,lnt,I?t)

(routine) 1 ( p : ex ression) i ivariat,It~-nlarnr,) (expression)

(FORTRAN-statement) : : - ( “any statement correctly processed by 1ocs:r.l FORTRAN compiler”)

(STYPE-statement) : : = STYPE [(basic-stype)]?’ (basic-stype) : : = (name>:([(s-formal)];) (name) : : = (letter) ) (name)(letter) / (name)(digit) (S-formal ) : : = (S-formal-D) / (S-formal-S) (S-formal-D) : : = (basic-decl) {S-formal-S) : : = (basic-stype) (DECL-statement) : : = DECL [(basic-deci)]; (basic-decl): : = [(var-name)(a-part)];: (type-name)(data-part) (var-name) : : = {name) (a-part) : : = {empty) ) ((index-part))

EX.GRAF 339

(type-name) : : = (name) (data-part) : : = (empty) / = (constant) (index-part) : : = [ (numbty)]; (numbty) : : = (empty) / (integer) (routine) : : = (r-head) (r-body) (r-head) : : = EXPR (preop) (operator) (postop) (pripty) i r-body) : : = BEGIN (code) END (operator) : : = (op. name) (op. name) : : = (character) 1 {op. name)(character) where character is a letter, digit or other typewriter symbol that one wants to allow for specifying operations. ipreop): : = (pars) (postop) : : = (pars) (pars): : = (empty) / (para) 1 ([(para)];) (para): : = (name) (pripty) : : = (empty) (, (integer) (code) : : = (statement) j (code) (statement) (expression) : : = (elementary-e) / (unary-use-of-O) (expression) /

(expression) (binary-use-of-O) {elementary expression) (unary-use-of-O) : : = (operator) (binary-use-of-O) : : = (operator} (elementary-e) : : == (constant) / (variable name) ( [ (expression} ] ;) (constant} : : = (elementary-constant) / ( (type-name ) :

[(elementary-constant)]?) (elementary constant) : : = (integer) I (real) / (Boolean) I (character) (variable name) : : = (name) / (name)(a-part) /

(variable name) . (variable name)

REFERENCES & BIBLIOGRAPHY

1. A. AH\K~, A Language for Interactive Design, in Gru&ic Lan~uu~!e.s, (Proc. (I$ IFIP Work- ing Conference on Graphic Languuges), Vancouver, Canada, May 1972 (F. Nake and A. Rosenfeld, Eds.), North-Holland, Amsterdam, 1972.

2. Il. F. BASKI~X ANU S. I’. MORSE, A Multilevel Modelling Structure for Interactive Graphic Design, IBM Systems]. 7, 1968, 218-228.

3. H. Hogans. K. LA\IR, R. ~IOBLEY AKI) J. RIEHER, POGO: Programmer Oriented Graphics Operation, Proc. SJCC 1969, Vol. 34, AFIPS, 1969, pp. 321-330.

4. P. BRAxC)I~.mT, J. I,EWI, LLI. SIKTZOFF. APIT]) P. L. WOIX~K, The Composition of Semantics in Algol 68, Comm. ACM 14, 1971,697-708.

5. K. GNATZ, On Basic Concepts of Higher Graphic Languages, in C:ml~hi~ Long~~uges, (Proc. qf ZFIP Working Conference on Gru$zic Lunguuges), Vancouver, Canada, May 1972, (F. Nake and A. Rosenfeld, Eds.), North-Holland, Amsterdam, 1972.

6. T. C. H.\(;AN, H. J, NIXOX, AND L. J, SCHAEFFER, The Adage Graphics Terminal, Proc. FJCC 1968, Vol. 33, Pt. 1, AFIPS, 1968, pp. 747-755.

7. J. HA~‘~AN>- .uw (Z. ICRAMMER, Do Graphic Languages Need to be Problem Oriented? in Cruphic Lunguuges, (Proc. of IFIP Working Con.ference on Gruphic Languages), Van- couver, Canada, May 1972, (F. Nake and A. Rosenfeld, Eds.), North-Holland, Amster- dam, 1972.

8. l-1. E. KCLSRUD, A General-Purpose Graphics Language, Comm. ACM 11,1968,247-254. 9. M. C. NE\VEY, An Efficient System for User Extendihle Languages, in Pror. F/CC 1968.

Vol. 33, AFIPS, 1968, pp. 1339-1347.

340 WILLIAMS AND KRAMMER

IO. 1%‘. hl. NEWXIAN, Display Procedures, Corn771. ACM, 14, 1971, 651-660. 11. A. 1). WtJl.I.Y, Subroutine Package for FORTRAN, IBM S!/,sterrt.v .I. 7. 1968, 248-256. 12. I’. %I. SCI~WI~N, A Problem-Oriented Graphic Language, in Pm,. ACM Xcdiorud Mwtir~::

1967, Association for Computing Machinery, New York, 1967, pp. 471-476. 13. 1). N. ShlITH, GPL/I-A PL/I Extension for Computer Graphics, in I’loc,. S,/<‘C .l!i,! L oi

38, AFIPS, 1971, pp. 511-528. 14. I. E. SUTI-IEIILAND, SKETCHPAD: A Man-Machine Graphical Comn~llnicutit~r~ .bvstc,m ii,

Pm,. S]CC 1963, Vol. 23, AFIPS, 1963, pp. 329-346. 15. H. ~t7ECHREI'I‘, “The Treatment of Data Types in ELl,” Tech. Report No. ESI)-TR-7 1~34 1

Harvard University, Cambridge, Massachusetts 02138, August 1971. 16. B. WEGHIUZI~‘, The ECL Programming System, in Proc. F:[CC 2971. Vol. 39, AF‘II’S. 1971,

pp. 253-262. 17. A. W ’IJ~GAWUEN, (Edj. Report on the Algorithmic Language Algol 68, Vtcr~wrisc~lrc~ !MufJtv.

mutik 14, 1969, 79-218.

19. H. WILLIANS, “A Systematic Method for the Creation of Data Structures ill (bmputc~l~ !;t,qir- its Applicatiorls,” Tech. Report No. 403-19, Department of Electrical Enginreriny artti Computer Science, New York Ilnivcrsity, Bronx. New York 10453, AprlI 197 I.

20. K. WILL,IAMS, “A General Purpose Graphical Language." Grcl))hic Ltrny~rog!cs. il’rcv i!/’ II, li’ Working Conference on Gruphic Languages), Vancouver, Canada, May 1972 iF, Snkt

and A. Rosenfeld, Eds.), North-Holland, Amsterdam, 1972. 21. N. i$'IHTH .&NI) H. WEHER, EULER: A Generalization of ALGOL and ith Formal Ihfinittc~ri.

Pt. 1, Comn~. ACM 9, 1966, 13-23; and Pt. 2, Comrn. ACM 9, 1966, 89-99. Sue &II: -zC:M Proc. of the Extensible Programming I,atrg~rages Symposium, Hostml, Ma)- 1969; SIC. PLAN Notices 4,8 (August 1969).