TELCOMP(ID:478/tel003)Joss variant for remote computingfor TELetype Computing BBN JOSS variant Developed to facilitate online programming as part of BBN's foray into creating subsidiary companies. The offshoot company itself was called TELCOMP, and operated in the area of Mass around BBN labs Version 1 on the PDP-6 had no on-line storage for either programs or data (PDP-6 because JOSS-II was PDP-6). TELCOMP programs were normally input via a paper tape reader on a Teletype (such as the ASR-33) which would be connected to a PDP via a modem and acoustic telephone line. Data could be read from the paper tape reader or from the Teletype keyboard. Output was either printed to the Teletype or sent to the paper tape punch. Used as part of the UCL Timeshare System, mentioned in Conversational Systems Used by BBN by Feurzeig et al to do the research that led to the esatablishment of LOGO. (Although LOGO was ultimately implemented in LISP) TELCOMP Commands (largely JOSS II) A TELCOMP program was made up of numbered lines, each line referred to as a Step. Steps were grouped into Parts. Each line contained one instruction. DEMAND Read input from the teletype DO PART Execute all of the steps in a numbered part DO STEP Execute a single line DONE Stop execution of current part and return to caller IF Condition, suffixed to any instruction FOR Loop, suffixed to any instruction PLOT Type output to the teletype in the form of a graph PRINT Print output to the teletype READ Read input from the paper tape reader SEND Send output to the paper tape punch SET Assign a variable to the value of an expression STOP Stop execution completely TO PART Go to a specified part TO STEP Go to a specified line TYPE emulate input for stored code ; Comment, suffixed to any line FORM A specification for formatted output Places Related languages
Samples: References: For the past two years, Raytheon Space and Information Division at Sudbury, Massachusetts has been exploiting the time-sharing environment for the benefit of its scientists and engineers. At first, a single terminal was rented and tied into a remotely located service offered by Bolt, Beranek, and Newman in Cambridge, Massachusetts. It was felt that as usage increased, additional terminals would be added to make use of the central computer. We were wrong. Before we needed a second terminal, the users required a second type of service. As the work load increased, a second terminal was added, but by then users were asking that a third type service be added. in Proceedings of the 22nd national ACM conference 1967, Washington, D.C. view details All application programs in this system are written in a high level interpretive language, a distant ancestor of which is JOSS,17 developed at the Rand Corporation in 1964. It has also been influenced by related languages such as TELCOMP and STRINGCOMP (developed by Bolt, Beranek and Newman, Inc.) and FILECOMP (specified by Medinet Division of General Electric Corp.). The MUMPS language allows the programmer to write a program, debug it, edit it, run it, and modify it concurrently at an interactive session at a console. The interpreter itself is a part of the executive system and is reentrant. The total space taken up by the time-sharing monitor, the input/output monitor, buffers, and reentrant interpreter is currently about 8,000 words of memory. The timesharing and I/O monitors have been specifically tailored to work efficiently with the interpreter. No attempt has been made to accommodate machine language user programs. in Computers and Biomedical Research 2(5) October 1969 view details External link: Online copy Extract: Introduction This paper describes a program written almost entirely in KDF9 ALGOL that will translate a source program written in one of the currently operational conversational languages TELCOMP into an object program in ALGOL text on paper tape ready for running. This allows the preparation of fault-free programs by means of conversational mode programming which may then be run on a larger, faster machine capable of accepting ALGOL. The translator is a two pass translator. In the first pass the standard functions are rendered into their equivalent ALGOL form or, if no equivalent exists, a procedure body is output on paper tape for inclusion in the object program. The various declarations real or array required by the object program are detected in the first pass and stored in a numerical form ready for output to the object program when the first pass is complete. To avoid overfilling the core store when a long program is to be translated each line of the source program is dealt with individually and then stored on magnetic tape. Extract: Aims of the program Aims of the program The primary object of the program was to accept any source program in TELCOMP 1 or 2 without restriction. The second aim was that the resulting ALGOL object program should be as close to normal ALGOL usage as would be consistent with the primary aim. Extract: The read procedure The read procedure The TELCOMP programs are run using a TELETYPE terminal, these terminals produce non-fixed parity IS0 code 8 hole paper tape. The English Electric KDF9 ALGOL compilers do not provide facilities to read mixed parity paper tape, and consequently input procedures were written in 'USERCODE' which is a low level language for the KDF9 computer. The input TELETYPE character code is translated to the internal KDF9 ALGOL basic symbol code by a directly addressable look-up table, operating during the transfer process. The look-up table is accessed by using the arbitrary numeric value of the input characters as a modifier address acting on the base address of the look-up table. Any odd characters, line feeds, carriage returns and erases are removed. The TELETYPE 'Control S' character is used to identify the end of a TELCOMP line of program. The TELETYPE paper tape character code has variations between the directly keyed program and that * Department of Building Science, University of Liverpool dumped up the line from the computer. Both codes have been made to produce a common sequence of basic symbols. The read in process is terminated by the presence of the word 'DUMPED' after a 'Control S' character which is the standard TELCOMP program terminating instruction. Extract: Types of instruction available in TELCOMP Types of instruction available in TELCOMP Each line of a TELCOMP program has a label. This is called a step number and it can lie in the range 1 to 99.99999. This step number is followed by one instruction only. The instructions allowed are described in the TELCOMP manual (1967). Most of these instructions can be followed by a list of expressions separated by commas which are controlled by the instruction. These are explained as follows: SET SET A=B, C= 1 x SIN(TH), D=LN(l+E) These are assignment statements that when written in ALGOL 60 would appear thus: A:=B; C:=l + sin (TH); D:= In (l+E); DEMAND and READ The operation of the instructions DEMAND and READ are similar. DEMAND interrogates the user for the value of a variable, READ reads the variable off paper tape. The instruction: DEMAND A, B, C would appear in the object program as: A:=read(20); B:=read(20); C:=read(20); TYPE, PRINT, PLOT and SEND The instructions TYPE and PRINT are output instructions that have a high degree of flexibility via a FORM (or Format) statement that controls the layout of a line of information output via the TYPE or PRINT instruction. PLOT is similar although the output is in graphical form. And SEND is a tape punching instruction that can punch any binary number in the range 0-255 on paper tape. These instructions can be matched by suitable ALGOL write commands except for the SEND facility which needs special treatment. DO and TO The instructions DO and TO are jump instructions. As previously stated a TELCOMP program is divided into steps. A group of step numbers each having the same whole number part is called a PART. A DO instruction can call either a whole PART or a part of a PART or a single STEP. The TO instruction is simpler in that control is not returned to the point at which the TO instruction occurred. Thus a TO statement can have only one expression following it and it is analogous to a goto statement in ALGOL 60. DONE and STOP DONE is an instruction that deems the current part number to have been done. Control is thus returned to the point at which the last DO statement occurred. The instruction STOP stops the action of the program entirely irrespective of the nesting of DO statements that may be current. Any of these instructions can be controlled by as many FOR or IF clauses as can be placed on one line. (Except that FOR cannot modify a TO instruction.) For example, the TELCOMP instruction TYPE A[I] IF A[I]> 1 FOR 1=1 : 1: 10, 20 would appear as in KDF9 ALGOL as for I:= 1 step 1 until 10, 20 do begin if A01 [I] > 1 then begin write (device number, format statement, A01 [I]) end end in The Computer Journal 12(3) 1969 view details in The Computer Journal 12(3) 1969 view details Introduction Conversational programming systems are enjoying a great vogue at present. Commercial time-sharing services are doing good business, and following the success of systems such as BASIC and of JOSS (alias TELCOMP alias JEAN) 'conversational FORTRAN' and 'conversational ALGOL' are being offered. However, these terms are not particularly well defined. Very often, all that is provided is a simple editing facility for source programs and an ability to communicate with the teleprinter at run-time, coupled to a more-or-less standard 'batch' compiler. (In one system of the author's acquaintance, the user of the conversational FORTRAN system is required to type his program as formatted card images, without the benefit of a TAB mechanism.) Another term that is used in this connection is 'incremental compiling', again, often without a clear definition. In this paper we aim to define the term 'conversational programming system' in a pragmatic way by considering the facilities that the user might expect to see. We then discuss various ways of achieving this for a FORTRAN-like language, including incremental compilation, and suggest a system that combines the external features that the programmer wants with reasonable internal efficiency. (As will be seen, this does not necessarily imply a fully interactive compiler.) Extract: City Conversational FORTRAN A few years ago a FORTRAN system was developed for student work at The City University: in order to achieve good diagnostics this system employed many of the techniques outlined in this paper, although it was intended for batch use. Unfortunately, no description of this significant piece of work was published at the time. in The Computer Journal 14(1) 1971 view details in The Computer Journal 14(1) 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 The Computer Journal 14(1) 1971 view details in Computers & Automation 21(6B), 30 Aug 1972 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 Computers & Automation 21(6B), 30 Aug 1972 view details in Computers & Automation 21(6B), 30 Aug 1972 view details Time sharing made feasible the economic use of remote distributed terminals and opened up the possibilities of interactive computer use in schools. We had recently implemented TELCOMP, one of the new breed of high-level interactive programming languages. TELCOMP was a dialect of JOSS, the first "conversational" (i.e., interpretive) language, developed in 1962-63 by Cliff Shaw of the Rand Corporation; its syntax was similar to that of BASIC, which had not yet appeared. Like BASIC, TELCOMP was a FORTRAN-derived language originally designed for numerical computational applications. Shortly after TELCOMP was created, we decided to introduce it to children as a tool for teaching mathematics and in 1965-66, under U.S. Office of Education support, explored its use as an auxiliary resource in eight elementary and secondary schools served by the BBN time-sharing system. Students were introduced to TELCOMP and then worked on standard arithmetic, algebra, and trigonometry problems by writing TELCOMP programs. The project strongly confirmed our expectation that the use of interactive computation with a high-level interpretive language would be highly motivating to students. Extract: LOGO based on LISP Incredibly, the best model for the new language (which was to be as simple as possible) turned out to be LISP, the lingua franca of artificial intelligence, often regarded (by non-LISP users) as one of the most difficult and formidable of languages. Of course, the syntax of Logo is much more familiar and accessible than that of LISP Essentially, though, Logo is LISP and is thus both an easy and a powerful language. The power is not evident in most existing microcomputer implementations, mainly because of their small memory and restricted performance. External link: Onlne copy at the Atari Archives in Ditlea, Steve (ed) "Digital Deli: The Comprehensive, User-Lovable Menu of Computer Lore, Culture, Lifestyles and Fancy by The Lunch Group & Guests" Workman Publishers: New York, 1984. view details BERANEK: In terms of mini-computers, we were doing paid research for DEC all the time after our purchase of the first PDP-1, and we could see where the market was headed. Of course, we thought we would be leaders in time sharing, which we were the first to. We even developed a programming language called TELCOMP that to this day, some say was better than the programming language that the industry adopted, namely BASIC. Our time sharing business had several early obstacles: the telephone lines were not reliable; the available input typing machines were too slow -- they were standard teletype machines; there were no big memories; and there were no fast printers. Then GE undercut us. We were just too early. But we assembled a roomful of DEC minicomputers and we purchased better storage equipment -- first the big reel cabinets from IBM and later the big flat disks from IBM. in Ditlea, Steve (ed) "Digital Deli: The Comprehensive, User-Lovable Menu of Computer Lore, Culture, Lifestyles and Fancy by The Lunch Group & Guests" Workman Publishers: New York, 1984. view details Resources
|