TINT(ID:480/tin006)Interpreted JOVIAL dialectfor Teletype INTerpreter Interpreted version of JOVIAL developed at SDC 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: TINT Description TINT Description TINT is a two-pass interpretive program system for time-sharing use, and operates upon a subset of the JOVIAL problem-oriented language. TINT includes a generator, a set of operator subroutines, and the interpreter. The generator was acquired from a current IBM 7090 JOVIAL compiler and was modified to handle the particular JOVIAL dialect used by TINT. The operator subroutines and the interpreter are original code developed specifically for TINT. The generator (first pass) scans the input JOVIAL statements and translates them into an intermediate Polish prefix language. Grammar checking is performed during the translation. The language subset allowed may include the arithmetic, relational, and Boolean operators ; procedure calls; data table, array, and item (integer, floating point, and Hollerith) declarations; and the GOTO, IF, STOP, READ, and PRINT statements. The READ and PRINT statements were added to the language specifically for time-sharing operation. Operator subroutines comprise the primitive functions used by the interpreter to perform the actions specified in the intermediate language. The interpreter (second pass) scans the intermediate language for the current operator prefix and its arguments, and executes the corresponding operator subroutine that computes on these arguments. The TINT user is permitted a number of options in composing and executing his code. He may reference code stored in a binary library tape of his own composition; he may file away any current code on tape for subsequent use, or for compilation with JTS after the code has been exercised and debugged; and, he may optionally execute code from a prestored tape or from the Teletype. 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 in [AFIPS JCC 25] Proceedings of the 1964 Spring Joint Computer Conference SJCC 1964 view details Unfortunately, the topics presented in this paper are covered in a cursory manner, providing few answers to the problems inherent in the nature of the subject matter. Thus the paper is a satisfactory introduction to current practices in time-sharing systems, but not as a detailed account of how the required objectives are achieved. Perhaps the most important contribution of this paper is its description of two interpretive compilers used with TSS; IPLTS, a version of IPL V, and TINT, a version of JOVIAL. These two interpreters, together with the debugging features provided, appear to present formidable tools to the online programmer. in ACM Computing Reviews 5(06) November-December 1964 view details in [ACM] CACM 9(03) March 1966 includes proceedings of the ACM Programming Languages and Pragmatics Conference, San Dimas, California, August 1965 view details in [ACM] CACM 9(03) March 1966 includes proceedings of the ACM Programming Languages and Pragmatics Conference, San Dimas, California, August 1965 view details in [ACM] CACM 9(03) March 1966 includes proceedings of the ACM Programming Languages and Pragmatics Conference, San Dimas, California, August 1965 view details in [ACM] CACM 9(03) March 1966 includes proceedings of the ACM Programming Languages and Pragmatics Conference, San Dimas, California, August 1965 view details in [ACM] CACM 9(03) March 1966 includes proceedings of the ACM Programming Languages and Pragmatics Conference, San Dimas, California, August 1965 view details TINT (Teletype Interpreter) TINT is an interactive programming system aimed at the casual programmer who has small-to-moderate sized programs. It uses a dialect of JOVIAL, and combines techniques of compilation and interpretation. TINT is designed to bridge the language gap between the computer and the non-programmer user; it operates interpretively, on-line. The on-line nature of the system makes it convenient to use. With TINT, the user can create, check out, execute, modify and re- execute a program directly from a remote teletype--and can often carry out the entire programming process at a single sitting. TINT is particularly suited to compact programs such as short mathematical problems, subprogram checkout, and other "one- shot" operations. Extract: TINT modifications TINT has been modified so that saved programs can be changed with the editing aid. This involved moving the location of the sequence number field. Work was begun on making TINT more useful to JOVIAL programmers by providing a command that will produce a copy of a program written in TINT which is suitable for compilation. Most of the incompatibilities have been taken care of, and work is presently going into the READ and WRITE areas. in [ACM] CACM 9(03) March 1966 includes proceedings of the ACM Programming Languages and Pragmatics Conference, San Dimas, California, August 1965 view details in [ACM] ACM Computing Surveys 2(4) Dec1970 view details in Computer Program Abstracts Cumulative Issue July 15, 1969 -- July 15, 1971 view details [321 programming languages with indication of the computer manufacturers, on whose machinery the appropriate languages are used to know. Register of the 74 computer companies; Sequence of the programming languages after the number of manufacturing firms, on whose plants the language is implemented; Sequence of the manufacturing firms after the number of used programming languages.] in Computer Program Abstracts Cumulative Issue July 15, 1969 -- July 15, 1971 view details The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one. There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages. The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM. Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) . It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers. The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA). As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found. It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel. We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work. Graz / Austria, May, 1973 in Computer Program Abstracts Cumulative Issue July 15, 1969 -- July 15, 1971 view details |