An important question to be asked by the system designer is whether the output responses will be of the types and in the formats that the client will expect to receive. It is noted in particular that "the closer the correspondence of the computer output is to the methods of presenting textual and tabular material familiar to the user, the greater his information absorption rate will be." (Morenoff and McLean, 1967, p. 20). Thus, in engineering applications, for example, the client may want results to be displayed in a familiar format such as a Nyquist plot.4.36 Similarly, in operations on files or data banks, the user should be able to structure and sequence files and subfiles for display and selection to suit his own purposes.4.37

For effective online operation, the system should provide responses within the reading rates of typical users, and with good resolution, little or no flicker, and with both upper and lower case.4.38 A some. what more specific and stringent list of remote terminal desiderata is provided by Licklider, with particular reference to the requirements of multiple access to the body of recorded knowledge. His desired features include, but are not limited to, color, or at least gradations of gray scale; 4.39 terse or abbreviated modes of expression to the machine with full or "debreviated" "“debreviated" response; 4.40 selective erasibility of the display by either program or user command, 4.41 and capabilities such as the following: "Shortly thereafter, the system tells me: 'Response too extensive to fit on screen. Do you wish short version, multipage display, or typewriter-only display?"." (Licklider, 1965, p. 50). Another design criterion affected by the factor of client convenience is that of the extent of display on the console face of meta-information.4.42

Continuing needs for technological developments have also been indicated for improved terminal and output display design. Examples include the development of new, fast phosphors and other materials,4.43 use of analog predictive circuitry to improve tracking performance,4.44 and variable sequencing of processor operations in computation and display.4.45 A number of advanced techniques are also being applied to large-screen displays,4.46 although some continuing R & D difficulties are to noted.4.47 Multiplexing of graphic display devices may also be required.4.48

Returning, however, to the human behavioral factors in input-output and terminal design, we note that man-machine relationships require further investigation both from the standpoint of human engineering principles and also from that of attitudes of clients and users,4.49 that there are continuing requirements for research and development efforts on both sides of the interface 4.50 and that, in all probability, "industry will require more special prodding in the display-control area than in the other relevant areas of computer technology." (Licklider, 1965, p. 66).

We note further an area of R & D concern that will recur in many other aspects of information

processing system design and use, and especially in information selection and retrieval applications. More specifically: "The major problem today in the design of display systems is that we cannot specify in more than qualitative terms such critical criteria as 'context' and 'meaning"." (Muckler and Obermayer, 1965, p, 36). Swanson adds: "Other restrictions derive from the need of programs to solve hidden line problems, to recognize context, and to make abstractions." (Swanson, 1967, p. 39).

Finally, we note the specific problem in documentary and library applications that large character repertoires are important to input and output representations of various levels of reference and emphasis in technical texts (especially, for example, in patent applications with multilevel referrals to accompanying drawings and diagrams) and to delineation of different types of possible access points in indexes and catalog cards.4.51 In addition, a wide variety of special symbols and/or exotic alphabets are typically employed in texts dealing primarily with mathematical, logical or chemical subjects. A text written principally in one particular language and alphabet may frequently use the alphabet set of one or more other languages, as in reference to proper names, citations, and quotations.

4.3. Character Set Requirements

For multiple-access systems "most creative users want large character sets with lower-case as well as capital letters, with Greek as well as Latin letters, with an abundance of logical and mathematical signs and symbols, and with all the common punctuation marks." (Licklider, 1965, p. 182). In addition, subscripts, superscripts and diacritical marks may be required.4.52

Attacks on problems of character-set requirements for output begin with on-line printer variations to provide larger output character-set vocabularies at the expense both of output printing speed and of prior input precedence-coding and/or of processor programming. programming. Larger characterset vocabularies are provided both by photocomposition techniques and by electronic charactergeneration methods, but again at the expense of either pre-coding or programming requirements.4.53

It should be noted, of course, that the internal language of most general-purpose information processing systems is limited to no more than 64 discrete characters, symbols, and control codes. Thus there must be extensive provision for multiple table lookups and/or for decoding and reencoding of precedence codes or transformation sequences, on both input and output, if any internal manipulations are to be performed on the textual material. In general, the larger the character set, the more elaborate the precoding and/or programming efforts that will be required.

Then there is the problem of setting up keyboard character sets that are adequate for application requirements and yet within reasonable

human engineering limitations. One proposed solution, the use of keyboard overlays and control codes to enable rapid shifting from one character subset to another, is exemplified by developments at Bunker-Ramo.4.54 Another possible solution to the character set problem as related to human engineering factors that is receiving continuing R & D concern is to provide multiple inputs via a single keystroke, such as "chord" typewriters or Stenotype devices.4.55

Regardless of what may be available through various conversion, transliteration, or translation processes on either input or output, there remains the question of the effects of internal character set upon sorting, ordering, filing and interfiling operations for a specific processor-storage system. For example, "other control elements which are frequently required in the design of information systems are special sorting elements. In a directory of personal names, such as those which might be found in an author bibliography, if names beginning with 'Mc' and those beginning with 'Mac' are to sort together, then special sorting codes must be entered into the computer for this purpose." (Austin, 1966, pp. 243-244)4.56

The size of an adequate character set is a particularly critical problem in at least two significant areas: those of automatic typographic-quality typesetting and of library automation.4.57 Complex character set requirements are also to be noted in such multiple-access applications as computeraided-instruction (CAI).4.58 Avram et al., considering automation requirements at the Library of Congress, stress that "keyboard entry devices must be

designed to facilitate the input of a variety of languages and diacriticals." (1965, p. 4). These authors point out further that "if the problems associated with the design of input keyboards and photocomposition printing devices can be resolved for the multiplicity of alphabets, there still will remain the formidable task of searching in a machine file which contains them." (Avram et al., 1965, p. 89). Similarly, Haring (1968) points out that the 128 symbols provided in the ASCII code is inadequate for the augmented catalog under development at Project INTREX.4.59

The very number and diversity of varied but realistic cataloging, filing, and search considerations in terms of character-set and sort-order requirements that exist today may indeed surprise the typical computer scientist facing library automation implementation problems. Nevertheless, particular problems of sorting, filing, and reassembly orders in terms of practical usage needs and acceptability to the clients of mechanized systems and services should be subjects of concern to designers of machine languages, machine character-sets, and of the processors as such.4.60

The even more difficult case of extensive mathematical, chemical, and other special symbols desired on output imposes additional hardware requirements, whether for high speed printers, photocomposition devices, or character genera

tors.4.61 4.61 This, then, is the area that has been called "Caligraphy by Computer." 4.62 A final example of unusual character set requirements is provided by "Type-A-Circuit" developments.4.63

The questions of design and development of appropriate programming languages and of processor design are obviously pertinent to all of the operations shown in Figure 1. As of 1967-68, however, special emphasis in terms of research requirements lies in three principal areas: user-oriented input, response and display languages; symbol manipulation languages capable of handling arrays of multiply interrelated data, and increasing interpenetration of hardware and software considerations in both system design and system use.5.1 For example, in the operations of developing processing specifications from client requests for service (Boxes 8 and 9 of Fig. 1), we need: new and more powerful problem-oriented languages; versatile supervisory, executive, scheduling, and accounting programs; hierarchies of programming languages; multiprogramming systems; improved microprogramming; new approaches to increasing interdependence of programming and hardware; and more versatile and powerful simulation lan

guages.

The overall system design requirements of the future indicate R & D concerns with programming languages, and especially with hierarchies of such languages at the present time.5.2 Controversies certainly exist as between advocates of more and more “universal" languages and proponents of problem-oriented or user-oriented machine communication techniques.

5.1. Programming Problems and Language

Continuing R & D requirements for programming language improvements represent two contradictory requirements: on the one hand, there is recognized need for increasingly universal, common-purpose languages compatible with a wide variety of systems, hardware configurations, and types of applications; and on the other hand for hierarchies of language systems. In addition, a number of special requirements for more flexible, versatile and powerful languages are just beginning to emerge, especially in such

areas as graphical communication, on-line problem solving, multiple access and multiprocessor control systems, simulation, and on-line instrumentation.

We are concerned here, then, with generalpurpose language and compatibility requirements; with special-purpose requirements such as problem-oriented programs, list-processing and other techniques for non-numeric data processing; with special problem areas such as very large programs and the requirements of multiple-access and multiprogrammed systems; with hierarchies of programming languages, and with the increasing interdependence of software and hardware considerations.

5.1.1. Problems of Very Large Programs and of Program Documentation

In terms of continuing R & D concern, we note first the problems of handling very large programs, defined as those that demand many times the available main storage capacity and that are sufficiently complex in structure to require more than ten independent programmers to work on them.5.3 An obvious requirement is to develop efficient techniques for segmentation: "When many programmers are involved, there is the problem of factoring the system into appropriate subtasks. At the present time this is an art rather than a science, and very few people are good at its practice, because of the inability to find useful algorithms for estimating the size and degree of difficulty of programming tasks." (Steel, 1965, p. 234). The questions of automatic segmentation, although recognized as critical and difficult problems, have therefore been raised.5.4

99

In particular, the checkout of very large programs presents special problems.* For example, "another practical problem, which is now beginning to loom very large indeed and offers little prospect of a satisfactory solution, is that of checking the correctness of a large program. (Gill, 1965, p. 203). Further, "the error reporting rate from a program system of several million instructions is sufficient to occupy a staff larger than most computing installations possess. (Steel, 1965, p. 233).

Other specific requirements in the programming problem areas include improved provision for adequate program documentation and related controls.5.5 For example, Pravikoff (1965) presents cogent arguments for the improved documentation for programs generally. Mills (1967) points to the special documentation problems in multiple access systems where users are less and less apt to be trained programmers.5.6 Dennis (1968) points to the present high costs of large-scale programming efforts as due to inadequate documentation that prevents taking advantage of programming already achieved, 5.7 while Kay (1969) considers the advan

*See also Section 7.1 of this report, on debugging problems generally.

tages of on-line documentation systems.5.8 Thus the area of program documentation requires further study and concern.

A related difficulty is that of inadequate means for translation between machine languages, although some progress has been made.5.9 An intriguing possibility deserving further investigation has been raised by Burge (1966, p. 60) as follows: "Presented here is a problem and a framework for its solution. The problem is as follows: Can we get a computer program to scan a library of programs, detect common parts of patterns, extract them, and re-program the library so that these common parts are shared?"

Another current question of R & D concern with respect to programming problems is of the generality with which a given language system can or cannot cope with a wide variety of system configurations and reconfigurations over time.5.10 The questions of development of more effective common-purpose or general-purpose languages involve very real problems of mutually exclusive features and of choices as between a number of means of achieving certain desirable built-in features.5.11

Areas of continuing R & D concern in programming language developments reflect, first, the need for increasing generality, universality, and compatibility (these objectives are followed in general-purpose language construction and standardization, on the one hand, and by increasing recognition of the needs for hierarchies of language, on the other); secondly, the special requirements of multiple-access, multiprogrammed, multiprocessor, and parallel processing systems; thirdly, requirements for problem-oriented and other special-purpose languages, and finally, needs for continuing advances in hardware-software balances and in fundamental programming theory.

5.1.2. General-Purpose Programming Requirements The presently indicated transition from exclusively batch or job-shop operation to on-line, multiple access system management 5.12 sharply aggravates the problems of programming language requirements in a number of different ways. First, there are very real difficulties in translating from programming languages and concepts geared to sole occupancy and use of system facilities to those required in the multiple-access, and multiprogrammed, much less the multiprocessor and network environment.5.13

As Brooks (1965) points out: "Today's excitement centers chiefly around (1) multiprogramming for time-sharing, (2) multiple-computer systems using a few computers for ultra-reliability, and (3) multiple-computer systems using a highly parallel structure for specialized efficiency on highly structured problems." 5.14 In all of these cases, moreover, the R & D requirements are typically

aggravated by a persistent tendency to underestimate the difficulties of effective problem solution.5.15

An obvious first common-purpose requirement is for truly efficient supervisory, accounting, and monitoring control programs 5.16 that will effectively allocate and dynamically reallocate system resources, that will be secure from either inadvertent or malicious interference, and that will be flexible enough to accommodate to changing clientele needs, often with new and unprecented applications.5.17

Also in the area of general-purpose programming requirements are the various emerging programs for generalized file or data base management, maintenance, and use.5.18 The first requirement, here, is for reconciliation of variable input, file storage, and output formats, together with flexible means for dupe checking on input, combinatorial selection, and output reformatting.5.19 Closely related are the questions of the so-called "formatted file systems." 5.20

A first approach to such general-purpose programming systems was undoubtedly that of the Univac B-O or Flow-Matic system developed in the mid-1950's.5.21 More recent examples include General Electric's GECOS III (General Comprehensive Operating Supervisor III) 5.22 and Integrated Data Store concepts; 5.23 the TDMS (TimeShared Data Management System) at System Development Corporation 5.24 and GIS (Generalized Information System) of IBM.5.25 Heiner and Leishman (1966) describe a generalized program for record selection and tabulation allowing variable parameters for sort requirements, selection criteria, and output formats.5.26

In 1965, comparative operation of file management was demonstrated by different systems including COLINGO (Mitre Corporation), Mark III (Informatics, Inc.), BEST (National Cash Register), Integrated Data Store (G.E.), and an on-line management system of Bolt, Beranek, and Newman, Inc.5.27 It was concluded that: "All of these systems were able to accomplish the processing required, but their approaches varied considerably, particularly in the file structures chosen for the application, executive control procedures, and level of language used in specifying the processing to be performed." (Climenson, 1966, p. 125).

In addition, we may note the examples of a file organization executive system,5.28 a program management system involving a two-level file,5.29 and a file organization scheme developed for handling various types of chemical information.5.30 Another documentation application involving a list-ordered file is provided by Fossum and Kaskey (1966) with respect to word and indexing term associations for DDC (Defense Documentation Center) documents.5.31

In the area of common-purpose languages, also, there is need to reconcile the differing requirements with respect to different classes of data structures,5.32 from those of numerical

While many advantages of list-processing techniques have been noted, a number of disadvantages are also reported. Among the major advantages are the recursive nature of list processing languages 5.35 and adaptability to dynamic memory allocation and reallocation.5.36 Also, languages of this type are "well suited to symbol manipulation, which means that it is possible to talk about the names of variables, and perform computations which produce them" (Teitelman, 1966, p. 29), and "by means of list structures . . . a three-dimensional spatial network can be modeled in computer memory. (Strom, 1965, p. 112).

Typical disadvantages to be noted include lack of standardization,5.37 degree of programming sophistication required,5.38 and wastage of storage space.5.39 Major difficulties are often encountered in updating and item deletion operations 5.40 and in dealing with complex data structures.5.41

We may ask also to what extent the available list-processing and symbol manipulation programming languages are adequate for current application needs? 5.42 To what extent are they useful for the investigation of further needs? In particular, it is noted that “unfortunately, while these languages seem in many ways directly tailored to the information retrieval work, they are also in other respects very awkward to use in practice." (Salton, 1966, p. 207).

List-processing languages and structures are particularly clumsy, moreover, for multiply interrelated and cross-associated data.5.43 Short of truly large-scale associative memories, effective compromises are needed as between list structures, including multilist programming languages, and file organizations that will provide economy of both storage and access. 5.44

Beyond list processing procedures there are trees, directed graphs, rings, and other more complex associative schemes.5.45 A relatively early example is that of "Rover" with "up links" and "side links" as well as "down links".5.46 Savitt et al., 1967, describe a language, ASP (Association-Storing Processor), that has been designed to simplify the programming of nonnumeric problems, together with machine organizations capable of high-speed parallel processing.5.47

Ring structure language systems are represented by Sketchpad developments 5.48 and the work of Roberts at M.I.T. for graphical data processing 5.49 and by systems for use in question-answering

and similar systems, such as Project DEACON.5.50 Still other associative structure developments are discussed for example, by Ash and Sibley (1968),5.5: Climenson (1966),5.52 Craig et al., (1966),5.53 Dodd (1966),5 5.54 and Pankhurst (1968),5.55

There are certainly those who need far more generalized multipurpose languages and, with equivalent force, those who advocate specialized, man-oriented, and special-purpose languages. A specific current design problem has to do with an appropriate compromise between these apparently contradictory comments. A future R & D requirement is to seek more effective solutions. Thus Licklider insists upon the need to bring on-line "conversational" languages more nearly abreast with the more conventional programming languages as an R & D challenge.5.

5.1.3. Problem-Oriented and Multiple-Access Language Requirements

Increasing needs for advanced special-purpose program language developments have been recognized for the areas of man-machine interactive problem-solving and computer-aided instruction applications, graphical manipulation operations, and simulation applications, among others. It is noted in particular that "their power [that of problem-oriented languages] in the extension of computing lies in the fact that the expert knowlledge of skilled analysts in particular fields can be incorporated into the programs, together with a language which is native to the field, or nearly so, and can thereby break down the barriers of economics, of lack of familiarity with the computer, and of time." (Harder, 1968, p. 235).

Important requirements in programming languages reflect, predictably, those of multipleaccess and time-shared systems involving a suitable hierarchy of languages so that the relatively unsophisticated user may converse freely with the machine without interference to other users or to the control and monitor programs and yet also draw upon common-use programs and data. The effective use of such systems in turn demands extremely tight and sophisticated programming to keep "overhead" to a minimum 5.57 and to provide dynamic program and data location and relocation. Relatively recent developments in this area discussed by Bauer, Davis, Dennis and Van Horn, Licklider, Clippinger, Opler, and Scherr among others.5.58 Bauer (1965, p. 23) suggests in particular that: “Entirely new languages are needed to allow flexible and powerful use of the computer from remote stations.'

and, secondly, that "the task of developing a complete new real-time language would be interesting and challenging since it would require reconsideration of the conventional procedure and data defining statements from the viewpoint of the real-time requirements." (Opler, 1966, p. 197).

Further, on-line problem-solving applications require dynamic and flexible programming capabilities.5.59 Experimentation with the working program should be permitted with due regard for system protection and control.5.60 Generalized problemsolving capabilities should be available in the language system without necessary regard to specific applications.5.61 Such programs should be extensively self-organizing, self-modifying, and capable of adaptation or tentative "learning." 5.62

Then it is to be noted that languages for on-line use should be relatively immune to inadvertent user errors.5.63 Teitelman comments, for example, that “in languages of this type, FORTRAN, COMIT, MAD, etc., it is difficult to write programs that construct or modify procedures because the communication between procedures is so deeply embedded in the machine instruction coding, that it is very difficult to locate entrances, exits, essential variables, etc." (1966, p. 28).

In language systems such as TRAC,5.64 the powerfulness is largely buried in specific machine processors for this language-the user is freed from learning a number of arbitrary exceptions, he is not able to "clobber" the underlying processor by inadvertent goofs, he is able iteratively to name and rename strings and procedures he wishes to use largely in terms of his own convenience, and he is able to make use of the language and system with minimal training or prior experience.

Related problems affect the design of specialpurpose languages ("the design of special-purpose languages is advancing rapidly, but it has a long way to go," Licklider, 1965, p. 66), the interaction of executive and console languages ("wherever remote consoles are used, we find the users enthusiastic. However, they always hasten to add that there is much to learn about the design of executives and processors for console languages,” (Wagner and Granholm, 1965, p. 287), the provision of adequate debugging aids ("the creation of large programming systems using remote facilities requires a number of debugging aids which range in complexity from compilers to simple register contents request routines." Perlis, 1965, p. 229), and the development of effective modularity in programs and compilers ("it will be necessary for the software to be modular to the greatest extent possible because it will need to work up to the next level of software." Clippinger, 1965, p. 211).

In connection with the latter requirement Lock discusses the desirability of an incremental compiler which is characterized by its ability "to compile each statement independently, so that any local change in a statement calls only for the re