LIPL(ID:2669/lip001)A linearized version of IPL-Vfor Linear IPL. A linearized (i.e. horizontal format) version of IPL-V. Related languages
References: Time-Sharing Applications To illustrate the "general purpose" nature of the Time-Sharing System, we focus on two interesting programming systems currently operating on TSS as service systems for the user. The first, IPL-TS, is a complete list-processing system for the Information Processing Language V developed by Newell, Simon, and Shaw. The second, TINT, is an on-line Teletype INTerpreter for the JOVIAL algebraic language developed by SDC. When the Time-Sharing System is equipped with these two programming-language systems, the user is immediately provided with a familiar programming system to ease his transition to programming for time-sharing, and allowed to use, with little or no modification, any code he may have previously written in IPL-V or JOVIAL for other machine systems. Extract: On-Line Program Composition On-Line Program Composition Both IPL-TS and TINT allow the user to write symbolic programs on-line and to execute them immediately, by themselves or in conjunction with previously coded routines. With IPL-TS, the programmer uses the special system routine, Linear IPL (LIPL),* which accepts IPL code on-line in a symbolic, linear, parenthesis format convenient for keyboard input. Figure 6 presents an example of LIPL being used to compose and execute Ackermann's function on-line. TINT, which was developed specifically for on-line program composition, accepts JOVIAL statements on-line in the same linear format used for compiler input. The ability to program on-line frees the programmer from having to concern himself with all the formalities of punched card accounting. With experience and facility, he programs online directly from his thoughts or, for more difficult problems, directly from a flow diagram, circumventing such time-consuming tasks as program-coding-sheet preparation, key punching, card sorting, editing, and prestoring. The time saved by the programmer can be applied to other coding tasks or to quality review of his current code. No programmer, of course, could compose a large program at one sitting with either of these systems, but this is a human, not a system, limitation; LIPL has no upper bound, and TINT'S 600-statement limit effectively exceeds a human's short-term comprehension. Optimally, these systems should be used for programs that can be written and debugged m one or two sittings (usually under 100 IPL instructions or 50 JOVIAL statements). There are three immediate consequences of this practical size limitation. First, many non-trivial, one-shot programs, such as for statistical computations, can be coded, debugged, and executed at one sitting. Often a programmer himself will refrain from writing such programs, knowing the time and effort involved. Figure 7 shows the Teletype communication resulting from an exercise using TINT as a "desk calculator" for computing the standard deviation of a set of research data. Second, large programs take on a modular structure; that is, large programs become a concatenation of numerous smaller programs and subroutines. Third, programmers begin to amass personal libraries of short utility subroutines, which they use to build larger programs. Clearly, consequences two and three would not exist, except in trivial cases, if it were not possible to work one day with code developed en prior days. Both IPL-TS and TINT provide this capability. TINT may accept symbolic input from magnetic tape, and can integrate this input with on-line Teletype input when so directed by the user. Thus the results of one day's coding can be filed on tape for later use. An alternative, if the symbolic JOVIAL statements have been executed and debugged, is to compile the code and save the binary output on a binary library tape, thus, again, integrating previous work with current code; however, the binary library approach has greatest value when used for utility routines. IPL-V is essentially a language of subroutines (composed from an inventory of some 200 system subroutines called J routines or primitives). Programs written in IPL-V are usually modular hierarchies of subroutines. Therefore, on-line composition of IPL-V programs is a natural extension of the language, and many alternatives for continuity of programming across many days of operation already exist within the language. For example, the programmer may "fire" a J166 (Save For Restart) at any time and continue from that point at a later date, or he may load a program from symbolic tape using the loader or J165 (Load Routines and Data) and continue using LIPL on-line. Therefore, the attributes of IPL-TS and TINT, when combined with a programmer's imagination and skill during on-line program composition, reduce significantly the tedious, uncreative tasks of code preparation and increase productivity. This point is particularly apparent to all programmers who have been required to debug code that they wrote several days earlier, and that has grown "stale" while it was being keypunched, compiled, and executed. Instead of expending additional time and energy becoming reacquainted with his code before he can correct his errors, the programmer can, by composing the code on-line and executing it immediately, debug while the code is still fresh in his mind. * LIPL was designed and coded by R. Dupchak while cons'iltant to the RAND Corporation, Santa Monica Extract: On-Line Program Debugging On-Line Program Debugging The particular ability of IPL-TS and TINT to detect, locate, and correct program errors online is perhaps their greatest asset, since it leads to substantial decrease in program turnaround time. In effect, IPL-TS and TINT increase the programmer's debugging efficiency by allowing him to check out more code per day than would be possible with non-time-sharing operation. Extract: Error Detection Error Detection is the first step in debugging any program. Errors may be classed as either grammatical errors in language or format, or logical errors in code execution. The generator screens out most grammatical errors for TINT, and either the loader or LIPL performs the same task for IPL-TS. Logical-error detection, however, is a more difficult task, even with IPL-TS and TINT. The advantage of these systems for error detection is their responsiveness to the programmer. He may choose to develop on-line, special-purpose debugging tools to suit his individual preference, or he may use those debugging tools provided by the system. For example, IPL-TS currently provides an error trap for some twenty illegal IPL operations resulting from faulty program logic; when such errors occur, IPL-TS attempts to provide the programmer with as much information as possible to help him correct his error. First, an error message is sent to the programmer to inform him of the error's occurrence and of its nature. Second, a special system routine, Trace Dump (discussed below), provides him with a "back trace" of the code leading up to the error to help him locate the cause of the error. Finally, the system pauses at a breakpoint, to allow him time to correct the error. However, all three steps may be altered, since the IPL-TS error trap mechanism is designed with a "thin skin" to allow the programmer to substitute his own trapping action in lieu of that provided by the system. With TINT, logical-error detection is left more to the imagination of the programmer. TINT allows the programmer to insert a PRINT statement, with numerous item names as arguments, at any point in his program. When it encounters this statement during program execution, TINT responds by printing on the user's Teletype the current values of all specified items. In this fashion, the programmer may take item snapshots at critical points in his program The power of the PRINT statement for logical-error detection is amplified when combined with the TINT READ statement The READ statement is the converse of the PRINT statement When TINT encounters this statement during program execution, the programmer must insert the current values of prespecified items By judicious use of the READ and PRINT statements, the programmer can repeatedly exercise a program with different initial conditions and review his results with input/output transfer-function analysis Thus, on-line user program communication increases a programmer s debugging efficiency by increasing his ability to detect program errors It is typical for a programmer, checking out new code with IPL-TS or TINT, to detect and correct half a dozen program errors in the first hour of operation, such error correction might easily have required a week with conventional programming systems Extract: Error location Error location The pinpointing of the erroneous code is often considered no different from error detection This may be true for grammatical errors but is far from true for logical errors The knowledge that an error exists does not, in and of itself, narrow the search for the error's location The user of IPL TS, there fore, is provided with a description of the system detected error and the aforementioned back trace of the code leading up to the error Back tracing by the system is performed in the debugging mode by the special system routine Trace Dump, which prints a full trace of up to the last 100 interpretation cycles, in reverse order (last cycle first) The number of previous cycles printed is controllable on-line Experience shows that the location of an error can usually be found within the first five cycles printed and that it is rarely necessary to go deeper than ten cycles back For logical errors not detected by the system the programmer has available all the standard IPL-V Monitor Point functions, m addition IPL TS extends these functions to include breakpoint operation as a programmer initiated option The option may be invoked at load time or during program execution In addition, the IPL primitive J7 (Halt) has been implemented as an alternative breakpoint mechanism When a breakpoint is encountered by IPL-TS, the programmer is notified and requested to enter the name of any regionally denned routine, which is then executed immediately Upon completion of the routine, the programmer is again queried He may continue to fire routines at the breakpoint or he may exit back to the prior program, the context of which has remained undisturbed. Breakpoints are not a panacea for locating erroneous code, however, they do provide additional control flexibility at critical points in a program In fact, the user of TINT must lelj almost exclusively on breakpoint logic for locating erroneous code the aforementioned READ and PRINT statements are in effect breakpoint statements For elusive errors these statements may be used to bracket groups of JOVIAL statements, and in extreme cases, individual JOVIAL statements TINT also provides a STOP statement, which is also a breakpoint statement When the interpreter encounters the STOP statement, the program is suspended until directed by the user to continue The user may also reexecute his program from a STOP breakpoint, or he may enter new code or edit prior code before continuing TINT'S STOP statement is analogous to the IPL-TS J7 (Halt) primitive. Extract: Error correction Error correction in symbolic code with either IPL TS or TINT is essentially on line program composition LIPL allows the IPL programmer to erase, extend, or modify selectively any user routine existing in the system TINT, similarly, allows the programmer to edit any JOVIAL code written, on a statement-by-statement basis Here, again, the programmer's control over his program is effectively increased He can correct code in several minutes instead of the several days typical with most computer installations Extract: LIPL LIPL was designed and coded by R. Dupchak while cons'iltant to the RAND Corporation, Santa Monica. in [AFIPS JCC 25] Proceedings of the 1964 Spring Joint Computer Conference SJCC 1964 view details in [AFIPS JCC 25] Proceedings of the 1964 Spring Joint Computer Conference SJCC 1964 view details in Bobrow, D. G. (ed) "Symbol Manipulation Languages and Techniques", Proceedings of the IFIP Working Conference on Symbol Manipulation Languages. North-Holland Publishing Co., Amsterdam, 1968 view details in Bobrow, D. G. (ed) "Symbol Manipulation Languages and Techniques", Proceedings of the IFIP Working Conference on Symbol Manipulation Languages. North-Holland Publishing Co., Amsterdam, 1968 view details |