IV DEVELOPMENTS IN SYSTEM-DESIGN TECHNIQUES

1A Introduction
1A1 They emerged from our experience with implementing and modifying our earlier on-line systems, and represent in themselves a significant part of our total research achievements.
1A2 The techniques provide considerable improvement in the following areas:
1A2A Speed and flexibility of implementing and modifying user features
1A2B Thinking about the different levels of system design and about the special design considerations at each level
1A2C Communication between system-development workers, and between them and users
1A2D Currency and quality of system documentation.

2A The service a user gets from the computer may be considered as a set of discrete operations of individual "service functions" from among the repertoire that comprise a "service system."
2A1 Examples of service functions are deleting a word, replacing a character, hopping to a name, etc.
2B Associated with each function of this repertoire is a "control-dialogue procedure."
2B1 Part of the dialogue consists of the sequence of meaningful user actions (keystrokes, select actions, etc.) -- this involves the following:
2B1A Identifying the desired service function
2B1B Setting up the necessary parameter designations
2B1C Recovering from mistakes
2B1D Calling for the execution of the function.
2B2 The other part of the dialogue, interspersed with these user actions, is made up of computer-feedback messages that help the user in proceeding through these actions.
2C We consider this repertoire of service functions, together with their control-dialogue procedures, to be the user's "control language." This is a language for a "master-slave" dialogue, enabling the master to control application of the slave's capabilities to his own service.
2C1 It seems clear that significant augmentation of one's intellectual effectiveness from the harnessing of computer services will require development of a wide and sophisticated control-language vocabulary.
2C2 It follows that the evolution of such a control language is a very important part of augmentation-system research.
2D For the designer of user systems, it is important to have means for specifying the nature of the functions and their respective control-dialogue procedures, so that a design specification will be:
2D1 Concise, so that its essential features are more easily seen
2D2 Unambiguous, so that all relevant questions about the design may be answered in a straightforward manner
2D3 Canonical, so that certain kinds of information can be found easily
2D4 Natural, so that the form of the description fits the conceptual frame of the design
2D5 Easy to compose, study, and modify, so that the process of evolutionary design can be facilitated.
2E For the user of such a repertoire, it is important to have a description of the nature of the service functions and of their associated control-dialogue procedures.
2E1 The description must be concise, unambiguous, canonical, and natural, for the reasons given above; furthermore, it must be accurate, in that everything relevant to the user about the service functions and their control-dialogue procedures is described, and everything described actually works as indicated.

3A Figure 6 shows a charting method that was used in earlier stages of our work for designing and specifying the control-dialogue procedure portions of our control language. Even though limited to describing only the control-dialogue procedures (i.e. not suited to describing the functions to be executed), this representation nonetheless served very well and led us develop the successive techniques described below.

3B Figure 6 shows actual control procedures for four service functions from the repertoire of our current interactive system: Delete Word, Delete Text, Place Up Statement, and Forward Statement. (The procedure flow is described below in the section on "Control Metalanguage.")
3B1 The boxes contain abbreviated descriptions of relevant display-feedback conditions, representing the intermediate states between successive user actions. Both to illustrate how the charting conventions are used and to give some feeling for the dynamics of our user-system control procedures, we describe briefly both the chart symbols and the associated display-feedback conventions.
3B1A The writing at the top of each box indicates what is to be shown as "command feedback" at the top of the display.
3B1A1 An uparrow sometimes appears under the first character of one of the words of Command Feedback.
3B1A1A This indicates to the user that the next character he types will be interpreted as designating a new term to replace that being pointed to -- the absence of an uparrow under Command Feedback signifies that keyboard action will not affect the command designation.
3B1A2 "Entity" represents the entity word (i.e., "character", "word", "statement", etc.) that was last used as part of a fully specified command.
3B1A2A The computer often "offers" the user an entity option.
3B1B The circle in the box indicates the state of the bug (the tracking spot), which alternates between the characters uparrow and plus.
3B1B1 The uparrow indicates that a select action is appropriate, and the plus indicates that a select action is inappropriate.
3B1C The string of X's, with underlines, indicates that the selected characters are to be underlined as a means of showing the user what the computer thinks he has selected.
3B2 Some of the output lines from boxes on the chart are marked with X's. This indicates that the computer is to wait until the user has made another action.
3B2A After this next action, the computer follows a branching path, depending upon what the action was (as indicated on the chart) to reach another state-description box or one of the function-execution processes.

4A In search of an improvement over the state chart, we looked for the following special features, as well as the general features listed above:
4A1 A representational form using structured text, so as to harness the power of our on-line text-manipulation techniques for composing, studying, and modifying our designs.
4A2 A form that would allow us to specify the service functions as well as the control-dialogue procedures.
4A3 A form such that a design-description file could be translated by a computer program into the actual implementation of the control language.
4B Using our Tree Meta compiler-compiler (see below), we have developed a next step forward in our means of designing, specifying, implementing and documenting our on-line control languages.
4B1 Figure 7 shows a portion of the description for the control language we currently use, written in "Control Metalanguage."

3 (wc:) zap case   

3A (b) [edit] dsp(backward tes*) . case   

.  

.  

.   

3B (c) [edit] dsp(copy ^es*) :s true => <am>adj1: . case   

3Bl (c) s*=cc dsp(^copy character) e*=c,character +bug2spec   

+cdlim(b1,p1,p2,p3,p4) +cdlim(b2,p5,p6,p7,p8)   

+cpchtx(b1,p2,p4,pS,p6);   

3B2 (w) s*=cw dsp(^copy word) e*=w,word +bug2spec   

+wdr2(b1,p1,p2,p3,p4) 

+wdr2(b2,p5,p6,p7,p8)   

+cpwdvs(b1,p2,p4,p5,p6);   

3B3 (l) s*=cl dsp(^copy line) e*=l,line +bug2spec   

+ldlim(b1,p1,p2,p3,p4) 

+ldlim(b2,p5,p6,p7,p8) :c st b1<-sf(b1) p2,   

rif :p p2>p1 cr: then (cr) else (null) , p5 p6, p4 se(b1): goto   

[s]   

3B4 (v) s*=cv dsp(^copy visible) e*=v,visible +bug2spec   

+vdr2(b1,p1,p2,p3,p4) +vdr2(b2,p5,p6,p7,p8)   

+cpwdvs(b1,p2,p4,p5,p6) ;   

.   

.  

.   

3b10 endcase +caqm ;   

3C (d) [edit] dsp(delete ^es*) . case   

3C1 (c) s*=dc dsp(^delete character) e*=c,character +bug1spec   

+cdlim(b1,p1,p2,p3,p4) +del;   

3C2 (w) s*=dw dsp(^delete word) e*=w,word +bug1spec +wdr   

(b1,p1,p2,p3,p4) +del ;   

3C3 (l) s*=-dl dsp(^delete line) e*=l,line +bug1spec...   

.   

.  

. 

4B1A This language provides the means for describing both the service functions and their control-dialogue procedures.
4B2 The Control Metalanguage Translator (CMLT) can process a file containing such a description to produce a corresponding version of an interactive system which responds to user actions exactly as described in the file.
4C There is a strong correspondence between the conventions of CML and the state chart, as a comparison of Figs. 7 and 6 will show.
4C1 The particular example printed out for Fig, 7 was chosen because it specifies some of the same procedures shown in Fig. 6.

4C2 For instance, the steps of display-feedback states, leading to execution of the "delete word" function, can readily be followed in the state chart.

4C2A The steps are produced by the user typing "d", then "w", then selecting a character in a giYen word, and then hitting "command accept" (the CA key).
4C2B The corresponding steps are outlined below for the CML description of Fig. 7, progressing from Statement 3, to Statement 3c, to Statement 3c2, to Subroutine +bugspec, etc.
4C2C The points or regions in Fig. 6 corresponding to these statements and subroutines are marked by (3), (3C), (3C2), and (+BUG1SPEC), to help compare the two representations.
4C3 These same steps are indicated in Fig. 7, as starting from Statement 3:
4C3A "D" sets up the state described in Statement 3C
4C3B "W" sets up the state described in Statement 3C2
4C3C The subroutine +bug1spec waits for the select-word (1) and CA (2) actions leading to the execution of the delete-word function.
4C3C1 Then the tcdlim subroutine takes the bug-position parameter and sets pointers Pl through P4 to delimit the word in the text.
4C3C2 Finally, the +del subroutine deletes what the pointers delimit, and then returns to the last-defined state (i.e. to where s*=dw).

5A Figure 8 shows the relationships among the major components of NLS.

Fig. 8 Basic Organization of NLS, Showing USe of Compilers and Compiler-Compiler for Implementation

5B The Tree Meta Translator is a processor specially designed to produce new translators.
5B1 There is a special language -- the Tree Meta Language -- to use in describing the translator to be produced.

5B2 A special Tree Meta library of subroutines must be used, along with the output of the Tree Meta Translator, to produce a new translator. The same library serves for every translator it produces.

5C For programming the subroutines used in our 940 systems, we have developed a special Machine-Oriented Language (MOL), together with an MOL Translator to convert MOL program descriptions into machine code. (SEE Hay, 1968 for a complete description.)
5C1 The MOL is designed to facilitate system programming, by providing a high-level language for iterative, conditional, and arithmetic operations, etc., along with a block structure and conventions for labeling that fit our structured-statement on-line manipulation aids.
5C1A These permit sophisticated computer aid where suitable, and also allow the programmer to switch to machine-level coding (with full access to variables, labels, etc.) where core space, speed, timing, core-mapping arrangements, etc. are critical.
5D The NLS is organized as follows:
5D1 The Control Processor (E) receives and processes successive user actions, and calls upon subroutines in the library (H) to provide it such services as the following:
5D1A Constructing a display view of specified data according
5D1B Putting display feedback on the screen
5D1C Locating data in the file
5D1D Manipulating working data to given viewing parameters, etc.
5D2 The NLS library subroutines (H) are produced from MOL programs (F), as translated by the MOL Translator (G).

5D3 The Control Processor is produced from the control-language description (d), written in Control Metalanguage, as translated by the CMLT (c).

5D4 The CMLT, in turn, is produced from a description (a) written in Tree MetaJ as translated by the Tree Meta Translator (b).

6A We have means for control-language specification that are much better than before, in terms of being unambiguous, concise, canonical, natural and easy to compose, study, and modify.

6B Moreover, the Control Metalanguage specification promises to provide in itself a users' documentation that is completely accurate, and also has the above desirable characteristics to facilitate study and reference.

6C Modifying the control-dialogue procedures for existing functions, or making a reasonable range of changes or additions to these functions, can often be accomplished solely by additions or changes to the control-language record (in CML).

6C1 With our on-line studying, manipulating, and compiling techniques, system additions or changes at this level can be thought out and implemented (and automatically documented) very quickly.
6D New functions that require basic operations not available through existing subroutines in the NLS library will need to have new subroutines specified and programmed (in MOL), and then will need new terms in CML to permit these new functions to be called upon. This latter requires a change in the record (A), and a new compilation of CMLT by means of the Tree Meta Translator.
6D1 Again, on-line techniques for writing and modifying the MOL source code (F), for executing the compilations, and for debugging the routines, make this part of our work much easier.