The interactive languages of Multipatch and Multiobject design systems

A. P. Armit

The interactive languages of Multipatch and Multiobject design systems This is the second of two papers describing curve and surface design using the two design systems developed by Dr. A. Armit. These systems are Multipatch and Multiobject, both of which are interactive 3D shape design systems.

Programming, Command and interactive Languages We may distinguish between programming command and interactive languages: 1. Programminglanguagesare usedby programmersto communicateprogramsto computers. 2. Command languagesallow usersof multiple-access systemsto causeentry to editors, compilers,etc., and private programs naming any necessaryfiles and peripherals.Subsequentinterpretation of user’sinput dependson the program entered. 3. Interaotive languagesallow users to control and communicatewith programswhile they are running. Often usersmay question or set numbers defining some‘designfeature’ or commandan evaluation of the designasa whole.Interactive languagesoften have a very large range of possiblecommandsand the high cost of looking theseup at time of useis certain. The structure of the languagecan be designedto help memory of the commands.On-line editors usually have simple interactive languages although these deal mainly in character strings. Although the boundaries between these types of languagesare indistinct generalcomparisonis possible: 1. Programminglanguagesneednot be straight-forward whereas command and interactive languagesdo, sincethey have to be linearly composedat a teletype. 2. Command languagesare ‘one-sided’since the user keeps telling the computer what to do (implying that the userknows). Interactive languages,however, allow a trial and error approach. 3. User’s errors with a Command language mostly oause complete command rejection and oblige the userto start again. Within interactive designsystems (where interactive languagesfind use) usersare not expected to get things ‘right tirst time’. To avoid excessivetyping during repeated trials, interactive languagesmay allow easycontinual referenoeto the place same (in a data-structure) compared with successive random references. The Interactive Languages Developed The interactive languages were developed for the Multipatch (2, 3, 4) and Multiobject (3, 4) 3D shapedesign systems(although they have been usedelsewhere).Some 10

features of thesesystemswere describedin the previous issue of Computer Aided DesignI. Both these systems respondto commandsin a fraction of a secondand various ‘results’appearon a graphicaldisplaywithin a secondor so. The form of the languageand implementation of the processor of Multipatch were developed together (one weekend)to give: 1. A short processor. 2. Minimum necessarytyped input. 3. A complete unambiguous typed record of the commands. 4. Flexibility to add new commandseasily. 5. A large range of possiblecommands. 6. Easy memorisingof commands. While basedon similar ideals the processorof Multiobject allows more ‘powerful’ commands; the processor isten timesaslong and took 100timesthe time to construct. Except for the vector-working of the extendedprocessorthe languagesare not (intentionally) biasedtowards 3D work or shapedesign. Multipatch’s Language Processor User’sView The need arose following the immediate rejection of singlecharacter teletype (or other input device) commands becauseof difficulty of memorising and becausesome hundreds of permissible commands were expected. A three letter mnemonic looked promising, but this was inadequateto specify which component (X, Y or Z) of which comer (labelled A, B, C or D) of which patch (numbered) was for change. The obvious step was a command consisting of a successionof hierarchical mnemonic‘names’so that PATA

X100$

might be interpreted to give entry to a routine to set the X co-ordinate of comer A of a patch to be 100. The problem (if only one number is acceptableper command) of ‘which patch’ was solved by the notion of designinga ‘currently selectedpatch’ - automatically set to a newly definedpatch and thereafter by commandslike PAT SEL 3 J. COMPUTER

AIDED

DESIGN

So design commands for a patch might contain: PAT 1 DEF & /create and selectthe patch PAT A X 100$ /position comer A of patch 1 PATA YlOOJ, PATAZ300J.

To minimisethe necessarytyping (etc.) the processorhas memory for the lastusednameat eachhierarchicallevel and for the last usednumber.This, together with the processor’s ‘search method’ (and indeed the hierarchical language structure), allows the differences between processor memory and required commandto be sufficient input. The above examplecan be given as:

/last usedtop level name /last used2nd level name ‘C’ ‘INZ ’ ilast used3rd level name

XKEYZ,

Ni3lTlC Memory (1 word per level)

‘PAT’

Fig. 1. Multipatch’s Processor’s Memory to routines executing commands).

(available

PAT 1 DEF J, A Xl004

YJ z 300 J-

As an aid to incremental design(where reversible and incremental commandsallow trial and error methods), a minus sign not followed by a number indicates the complement of the rememberednumber. Thus: PATA ,.

INX

- 4. 4

PAT DEF

RI

PAT SEL

R2

PATA

R3

/repeat PAT A INX 100 /execute PAT A INX -100 /repeat PAT A INX -100

Programmer’s View The processorchecks user’s input against a language definition held in hierarchical name-addresslists. Only the starting addressof the (unique) top level list is made known to the processor- allowing immediatemodifioations of languagedefinition. Figures 1, 2 and 3 show the format of the processor memory and an example language definition. Following the code for eaohnameis an address - either the addressof a lower level list of namesor the address of the routine to execute the command (distinguished by ‘JMP’), Fig. 3. Supposethe userhasjust terminated a name(by spaceor carriage return). The processorcomparesthe nametyped with the namesin the top level list (starting at address XKl). If a correspondenceis found the processoroverwrites the top level memory word with the nametyped. Otherwise the top level memory word is usedto find its list of seoond level nameswith which the typed nameis then compared. If a oorrespondenceis found the seoond level memory word is overwritten; otherwise the processorcontinuesto searoh lower level lists. If no correspondenceis found before the processorruns out of lists to searchthe userhas typed an unknown name and the processoroutputs a fail message.When a command is obeyed the namesin the processormemory are usedto trace the languagedefinition to find the addressto which control is passed. While 1971

Routine to be entered

1004

Thus the necessaryinput to the processordecreases at just the right time - when the user has focused his attention (and the processor memory) on the thing he wants to change. The form of the languageallows direct interpretation of the user’sinput so that unknown namesare rejectedimmediately they are terminated (by space, etc.) ensuring that a maximum of three charactersare sufficient to correct any typing mistake.

AUTUMN

Command __--------

X BY cz D ZNX INY

INZ VIE SEL

R4

VIE VIS INV

RS

.HLT

STOP

languagedefinition I I

PAT

I DEF

I

SEL

IIII

I

I

VIE

HLT

I IIII

A

B

C

D

I

SEL

J

INV

I

VIS

I I I I I I

X Y Z INX Fig. 2. Example

INY

INZ

Commands

and their structure.

allowing minimum userinput this searchmethod disallows the olash betweenany name and any name in any of the lists leading to that name. In practice this type of olash would confusethe user asmuch asthe system. The languagedefinition in Figs. 2 and 3 does not give entry to unique routines for each permissiblecommand. Not only is the routine R3 sharedbetweencommandsbut the languagelist at XK3 is shared by PAT A, PAT B, PAT C, and PAT D. The routine at R3 determineswhich of 17

the 24 permissible commands caused entry by examining the ‘history of access’ in the processor memory. Since the commands are unique there is no problem masking or interpreting the memory to yield offsets to data-structures, etc. For systems with many commands (produced by a few names at several levels) the shared language lists and routines show a great space saving. (The 350 Multipatch commands were implemented in about 1500 words.)

XKl,

Light-Pen Version The simple interactive language of Multipatah may be presented on the graphical display as light-buttons for the user to select with the light-pen, Fig. 4. (The language definition and the routines entered are unchanged.) Before oommand completion the hierarchy of the language ensures there is a range of acceptable ‘next-names’. This range alone is displayed to minimize difficulties in finding a required name and to prohibit the construction of illegal commands. This helps new users, but typed input can be quicker. Extensions to the language quickly make light-pen control oumbersome (many pen-hits needed).

XK2,

‘A’ XK3 ‘B’ XK3 ‘C’ XK3 ‘D’ XK3 ‘DEF ’ JMP Rl ‘SEL JMP R2 LAM

/seoond level list to PAT /address of lower level list to PAT A

XK3,

‘X’ JMP ‘Y’ JMP ‘Z’ JMP ‘INX’ JMP ‘INY’ JMP ‘INZ’ JMP LAM

/third level list for PAT A, B, C or D

Conclusions on Multipatch’s Processor There were various inconveniences of the language processor of Multipatch (related to the requirements of this system) : 1. The necessity of directing commands to the currently selected patch could produce a sequence:

XK2 ‘ VIE’ XK4 ‘HLT ’ JMP STOP LAM

PAT 1 SELJ. CLE 4 ZSELJ. CLE 4 3 SEL$ CLE 4 to clear three patches of their screen labels. 2. The extremely simple command structure forced input for, say, the X co-ordinate of corners A, B, C and D of a patch to look like: PATA X 1004 B 200 4 C3OOJ. D 400 4. with four separate commands necessary. 3. Questioning of values in data-structures was not as easy as specifying such values. Separate commands were necessary (to distinguish between them). For example all the comer co-ordinates of comer A were output to the teletype by

‘PAT’

XK4,

/top level list - this address known to processor /address of lower level list to PAT /other top level names

/terminator to top level list

R3 R3 R3 R3 R3 R3

‘SEL JMP R4 ‘VIS’ JMP R5 ‘INV’ JMP RS LAM

/second level list for VIE

Fig. 3. Example

language

Fig. 4. Light-pen Multipatch.

input

definition.

PATAPOIJ However, the importance of the language processor had become clear - the ability of Multipatch to cope with patch joins and continuity and to provide a stable design procedure, etc., could only be given to the user through the language processor. Multiobject’s Language Processor Multiobjeot is a much larger system than Multipatch with many more facilities. The extended language processor of Multiobject overcomes the difficulties of the earlier processor while remaining able to process commands in the simple form. 12

of commands

COMPUTER

to

AIDED

DESIGN

User’s

View

Argaments Perhapsthe most important changeis the acceptability of argumentsto the names(at eachhierarchicallevel). The processor remembers the last specified name and its arguments at each hierarchical level and also the last specified succession of numbers (outside argument brackets). Routinesare enteredas before, usingthe names to trace the languagedefinition and eachroutine may take none or more argumentsat each hierarchical level, and none or more numbers,asdecidedby the programmerand madeknown to the user. The notion of currently selectedpatch (etc.) is retained, but commandslike PAT(2) would

A x 100;

NameLoops Nameloopsare of the form

which is equivalent to PAT(l) A X 100; B 200; C 300; D 400; Nameand argumentloopscan befreely mixed, for example PAT(1 2) A, B X 100200 300 400; to mean PAT(l)

refer to patch 2 while

A, B, C, D X 100200 300 400;

PAT(I)

A X 100; R 200; PAT(2) A 300; B 400;

Or, the argument loop example re-written but with the samemeaning

PAT A X 100;

CUR(l), CUR(Z) T(5 6) IX 20 30 40 50; would refer to the ourrently selectedpatch (as before). Loops Following (successful) execution of the command, control returns to the processorwhich determinesif any arguments remain to be made available to the routines exeoutingthe commands.For example, if Argument

PAT(1

2) A X 100 200;

is typed, only the first argument ‘1’ and the first value ‘100 are absorbed by the tirst entry to the routine. So the prooessorcausesthe samecommandto be enteredwith the secondargument ‘2’. Thus an ‘argument loop’ is formed and the example becomesequivalent to PAT(I)

A X 100; PAT(2)

200;

The exact operation of the processoris to form (nested) loops so that CUR(1 2) T(5 6) IX 20 30 40 50; is equivalent to CUR(l)

T(5) IX 20; T(6) 30; CUR(2)

T(5) 40; T(6) 50;

wherethe command CUR T IX usesone argumentat both first and secondlevels. When no loops remain, left-over numbers indicate at least user inconsistencyand probably error. An error is signalledif any numbersare given in the current command and they are not all used, or if no numbersare given and somebut not all of the rememberednumbersare used.

1) INV; can be arranged to make all patches (except none) or all views except number 1 invisible. To keep the routine entered unaware of the ALLX mechanism,the language processorrelies on routines to trace patches, views, etc. whioh are clearly system dependent.For this reason the ALLX mechanismis not built into the processorbut is ‘imposedon top’. AUTUMN

1971

INV;

CUR(l) T (2)

X (CUR(3)

T(4)

Y;

to execute ‘CUR(3) T (4) Y’ to extract a number which is then used as the value for ‘CUR(l) T (2) X’. So just as the left-hand sideprocessor(often) enters a routine to put numbersinto data-structures,the right-hand sideprocessor enters routines to extraot numbers from data-structures. The left and right sideshave separatelanguagedefinitions, allowing exactly the sameform of command for number input/output. Data fetch routines may perform much arithmetic upon numberstaken from data-structuresbeforeyielding a result. For example,in Multiobject the co-ordinatesof a point on a surfacemay be questionedby specifying two parametric values,although the result is calculated rather than merely extracted from a data-structure. Sine, cosine, root-sum-of-squares,vector product, etc., are provided by data fetch routines which merely operate on their arguments (not consulting user built datastructures)to yield results. Using the facilities of arguments,loops and data fetch the inconvenient examplesof Multipatch’s processormay be written PAT(1 2 3) XCLE; PAT A, B, C, D X 100 200 300 400; TTY = (PAT A XYZ;

Vector and Scalar Arithmetic A commandlike

The ‘All-except’ Mechanism Commandslike PAT(ALLX)

Data Fetch To assistin questioningvaluesin data-structures‘Righthand side’ processingis added, allowing

VIE(ALLX

PAT(l)

A XYZ

100 200 300;

is already acceptable (becausethe vector is effectively handledby the routine entered,not the processoritself) but the processorallows extraotion of values by vector, for example PNT(l)

XYZ

= (PNT(2)

XYZ; 13

extracts the X, Y and 2 co-ordinates of point 2 and then uses these for the oo-ordinates of point 1. Coupled with data fetch the arithmetic allows the user to set any number in any data-struotureto ‘any’ function of any numbersin any data-structures. Vector and scalar expressionsmay be written, for example TTY = 2+ (PNT(2) XYZ; types the resulting vector. Scalar and vector variablesmay be defined,for example TOP and VI by SVAR

DEF(TOP)

2; VVAR DEF(V1)

3 4 5;

and thereafter resetby SET(TOP)

6;

Variables may be usedwherever a number may occur within arguments,expressions,etc. Minimum Input There area numberof waysof decreasingthe typed input to the processor. Apart from the usual separator and terminator there is the notion of repeater (usually I,‘). Excess‘,’ (that is above the first) causethe repetition of the preceding number, variable (possibly vector) or argument. For example CUR(1 2) T(1) X IOO,,; is equivalent to CUR (I 2) T(1)

X 100 100;

The userneednot supply right bracketsbefore the major commandterminator ‘carriage return’. Except for macro definition and use,right bracketsneednot be given before the minor commandterminator ‘;’ or beforethe expression introduotory character ’ = ‘.

(Character strings are enclosedin square brackets and f may signify the argument substitution character.) The Environment of the Processor in Multiobject The user’styped input is buffered until the ‘carriage return’, when it is passedto the languageprocessor.Until this time ‘rubout’ deletesthe last character (and reflects it to the teletype) and ‘@’ followed by a character deletes from the end back to the last occurrenceof the character. (The whole input is deleted by ‘@’ followed by ‘carriage return’). ‘Linefeed’ reflectsa ‘carriagereturn’ to give more paper spacewithout input to the buffer. To easeuseof the languageprocessor,Multiobject can display the user’slast input, the rememberednumber list, command and data fetch, and the values of any scalars, vectors or macros defined. When an error occurs a fault type and number and any unprocesseduser’sinput is also displayed. (The fault information and unprocessedinput may also be typed.) Programmer’s view The interpretation of an input character string depends on the commanddefinitions, processorinput memory (as before) but also macro and variable data-structures. The languagedefinition is exactly the form already desoribed; Fig. 5 shows the structure of the processor command memory. The left-hand side processorabsorbsthe user’s (buffered) input, allowing for variablesand macros, up to the first command terminator while building a modified input memory. At time of usemacrosare undumpedbackwardsinto the input buffer (with any argumentsubstitutions made).Thus multi-depth macrosneedno specialattention. At commandexecution the loop memory is set from the input memory, and the execution memory from the loop; the routine is then entered. The ‘history of access’and argumentsare available through the execution memory. (A processorroutine may becalled to extract an argument/ next argumentat a stated hierarchical level, modifying the execution memory if necessary,and to determinethe type of the argument.) After commandcompletionthe processor

Macros The usermay define character macrosso that wherever the macro name(with any relevant arguments)is detected in subsequentinput it is replaced by the stored macro definition. Macros may contain referencesto macros.For example,if Ml is defined asA, B, C, D

INPUT

MEMORY

Names and arguments

Types

PAT Ml Z lo,,,,;

is equivalent to PAT A, B, C, D Z 100 100 100 100;

Macros may contain several commands, for example with Cl definedas SET(S1 S2) = 8 = 5; TTY = S2 = (CUR(S1)

BE(S2)

Pointers

XYZ

execution

then Cl[l 3O/S3]; is equivalent to

I

I

LOOP

SET (Sl S2) = 1 = 3O/S3; TTY = S2 = (CUR(S1) BE(S2) XYZ;

74

Fig. 5. Command processor).

1

MEMORY

memory

,

EXECUTION

MEMORY

(Multiobject’s

COMPUTER

language

AIDED

DESIGN

STRUCTURED Oaracters

CHARACTER Back offsets

reverts. Within the processorthe same routines are used to operate on left- or right-hand-side memories. Similarly the routines entered to question or set values in datastructurescan have a lot in commoo.

BUFFER

tx?:

Names & args

Types

SCALAR & VECTOR INTERMEDIATE VALUE STORAGE PSEUDO-FLOATING-POINT Signlflcant bits I Signs&shifts II I

I

1

Fig. 6. Buffers used during expression and data fetch (Multiobject’s language processor).

tries to advance the execution and loop memory from the lowest relevant level upwards to find a commandloop. If successful,any lower levelsof loop and exeoution memory are reset from the input memory (causing nested loops) and a new (possibly the same)routine entered. When no (more) loops exist the commandis oomplete. Right-hand sideprocessingoccursafter an ’ = ‘. Charaoters from the user’sbuffer are fed into a structured buffer, Fig. 6, while uodumpingmacrosand replacingvariables by singlecharaoter identifiers. Left and right brackets are fed into the structured buffer to isolate operators with terms. The structured buffer is then simplified by successive evaluation of the first complete ‘term-operator-term’ located. This processis complicated by the co-existenceof expressionsand data fetch with arguments (which may alsoneedevaluating). While the order of expressionevaluation is dependenton operator and bracket placement,data fetch and parts of data fetch must be ‘presentedto the input memory’ in written order. (Strictly the Brst located data fetch whose argumentsare not themselvesdata fetch is successivelypresented.) This conflict tends to produce values for parts of an expressionand arguments at ‘inconvenient’ times. Several intermediate buffers are used to store such values during processing.When the evaluation is complete the result is usedeither as an argument or number by the left-hand-side processorto which control

Conclusions on Multiobject’s Processor The language appears to approach a good balance between minimum typing, maximum intelligibility and easeof memory in commandslike ‘CLIR(I) T(2) 1X200;’ and ‘VIE(3) lG; Three hierarchical levels of names proves necessaryalmost only when the third is used to indicate X, Y or Z components.Command namesonly occasionally use the four character maximum - three charactersis usually ample. New users might well find the language difficult, especiallymacros, vector products and perhapscommand loops. A lot can still be achieved without using these features, but the amount of typing tends to increase. Complex macros, for example to construct evolutes to curves, are too diacult to linearly composeand type while using Multiobject. Such macros have been coostruoted away from the systemand then fed in, and saved(like any other Multiobject data-struoture)for later use.This facility allowsconstruction of appropriate macrosfor thejob to be tackled, and avoids any re-programming of the system (although this would be desirableif the systemwerealways to be usedfor the sametask). The use of macros in praotice has been almost exclusively to execute a pre-definedset of commands,with a few numberspassedover as arguments- subroutinesrather than to indulgein complex characterhandling. Such a simple use doesnot require the complex provisions of Multiobject’s processor- a substantial processor saving accruesif the permanentworry ‘what if the next bit is a macro’ does not occur in the middle of command processing. 10 a re-implementation, the programming power of the languagewould be increasedto allow even more control to be wielded without changing the system in use. By excluding the more general macros the left and right side prooessingcould becomemore interwoven, resulting in a shorter processorand removing minor ineleganciesin the input language. References 1 Armit, A. P.: ‘Curve and SurfaceDesignusingMultipatch and Multiobject DesignSystems’.Compufer Aided Design Vol. 3, No. 4, Summer1971. 3 Arrnit, A. P.: ‘A Multipatch DesignSystemfor Coons’ Patches’.IEE ConferencePublicationNumber 51, April 1969. 3 Armit, A. P.: ‘Multipatch and Multiobject DesignSystems’. Proc. Roy. Sot. London.A.321 (1971). * Armit, A. P.: ‘ComputerSystemsfor Interactive Designof Three-Dimensional Shapes’.CambridgeUniversity Ph.D Thesis,November,1970. Received July 1971

Following a 9 month apprenticeship at the Marconi Wireless Telegraph Company in 1963, A. P.Armit, M.A., Ph.D., read Mechanical Sciences at Cambridge University Engineering Department under a Caltex Scholarship scheme. After some work on furnace rating and pipeline design he left Caltex to join the British Aircraft Corporation, Stevenage, to become involved in analogue and digital circuit design. At about this time his book on Vectors for A-Level students was published by Heinemann. Under a BAC Scholarship he returned to Cambridge in 1967 to read for a Ph.D. in ‘Computer-Aided Design of ThreeDimensional Shapes’ at the University Computer Laboratory. During this time ‘Multipatch’ and ‘Multiobject’ design systems were constructed. Now back at Stevenage he is involved in the applications of c-a-d. within BAC.

AUTUMN

1971

15