UNCL(ID:3251/)Language for the TEACH systemBased largely on CITRAN (hence JOSS) but trying to add more features from MAD/ALGOL Scripts interpreted by a program called AEGIS, which then brokered the requests with the monitor. Related languages
References: This system is similar to the CITRAN system which has been available at California Institute of Technology for at least three years. That system has a Joss base, and features a built-in manual invoked by calling the program HELP. One could (and often did) learn how to program using this manual, although the manual was not specifically designed for this purpose. This area could benefit from further work. The principles and equipment that have been proven for CAI should be incorporated to allow better instruction and lower cost. Another system, known as PAT, has been used at MIT for teaching programming concepts to computer scientists. It is hoped that this system and others will soon be presented and compared. Eventually, no faculty member should be needed to teach a beginning course in programming for applications. in ACM Computing Reviews 11(07) July 1970 view details Tools and Goals It seemed clear to us that, whatever the state of computer-aided instruction (CAI) with respect to other subjects, the computer is the ideal instrument for teaching its own use. If a computer is to be used to teach any laboratory subject, then it will have to be made to simulate that laboratory during some stages of the instruction. This imposes severe difficulties in most cases. But a computer can be made to simulate a computer quite easily. Also, a large part of any laboratory course consists of the student's actual experience with the hardware of the laboratory. In the computer-based teaching system which we have developed, the student is manipulating the laboratory hardware from the very beginning of the course and throughout his instruction. The major resource we had available to us in the summer of 1967 was the Compatible Time Sharing System (CTSS) [1]. This includes a large number of typewriter consoles, an IBM 7094 computer, and a generous set of software facilities. Of these software facilities, the most important to us were the CTSS file system, a good algebraic language (MAD), a list-processing language (SLIP), and, of course, facilities for typewriter-computer communication. We began by setting certain objectives. Chief among these was that we intended to teach programming, not some particular programming language. We realized, of course, that some programming language was required as a vehicle to convey the ideas we intended to communicate. Our task of designing such a language was governed by the following criteria: (1) A student, having learned our language, should be able to learn any standard algebraic language very quickly, on his own, simply by studying the manual for that language. (2) Our language should, accordingly, contain all the fundamental ideas of current programming practice. These should be clearly identified and appropriately named-- we should not introduce new jargon. Examples of such ideas are: identifiers and variables, control of iteration, recursion, subroutines, and user-defined functions. (3) Every important idea should be presented only after a need for it has been clearly established. Before an idea is presented to a student, he should be brought to the threshold of inventing the idea himself. For example, he should have had to write a particular program segment several times within a single program before the introduction of the idea of the subroutine. While this criterion is more one of pedagogy than one of language design, it translates into the latter. In particular, it dictates the dependency relationships between the various modules which, when finally joined, constitute the whole language. It determines, for example, that facilities necessary for construction of large program segments must be made available before mechanisms allowing true subroutining. Hence, for example, loop control mechanisms must be independent of subroutine mechanisms. (4) When a particular facility can be provided in a number of different ways, the design that is capable of being explained most simply and clearly is to be chosen. We believe in general that an implementation that is hard or awkward to explain is probably wrong. The faithful adherence to this design criterion has led us to deep and searching discussions about questions which appeared initially to be simple and even superficial. Our own understanding of language design has deepened and, we believe, the language we have produced is uncommonly clean. Surrounding the language processor is a teaching system which presents lessons to the student, supervises his progress, and permits him to exercise his skills. Before beginning the detailed design and implementation of this supervisory system, we agreed upon a number of criteria. Among these were: (1) The individual student's rate of progress through the lesson material is to be governed by the student's own actions. Each student must be given a separate filing area for his work. (2) The system must remember the individual student's level of progress at all times. System bookkeeping limitations, for example, ought not to make it necessary for the student to repeat or reconstruct work. (3) The system must detect student errors as quickly as possible, whenever possible in a highly localized context. Once an error is detected, it is to be pointed out to the student in as unambiguous a fashion as possible. Finally, the system must permit the student to correct errors locally, i.e. without forcing him to reconstruct large portions of error-free work. (4) The system must be totally protected against system failure due to student error. (5) The system must be modular, so that changes (either in the language to be taught or in the lessons themselves) can be made easily and independently of one another. Extract: System System In accordance with these criteria, the TEACH system was developed to provide virtually instructorless instruction in programming. At the heart of the TEACH system is a language which we have chosen to call UNCL. We believe that UNCL meets the first set of criteria mentioned above. UNCL is an interactive language which somewhat resembles Joss, but it differs from Joss and other Joss-like languages in several major respects. A result of these differences (e.g. the presence of block structure, a context editor, and a function-tracing feature) is that UNCL is somewhat more amenable to rational explanation (say, in the metaphors of mathematics), while it is somewhat less amenable to cookbook explanation (the language may not be as appealing to nonprogrammers). Significantly, UNCL (like Joss) may be used as if it were merely an expensive desk calculator. It is sufficiently rich, on the other hand, that quite complex computational tasks are well within its domain. Surrounding the UNCL interpreter is another, much simpler interpreter called AGes. Programs written for AGES are called scripts. The AGES language is quite general; AGES allows arbitrary recursion, conditional transfers, scanning of student input for keywords, etc. However, the body of scripts which now exists uses little of that generality. This body of scripts constitutes an elementary course in computer programming. The most prominent activity of these scripts is simple typing of information to the student. The material typed is, in sum, a careful text in computer programming. It is divided into 18 chapters, each with 5 to 10 sections. The chapters and sections are the calibrations of a ratchet-like mechanism maintained by the scripts. This mechanism allows a student to leave the system and to return days or months later to the point from which he left. The scripts are able to call upon the UNCL interpreter. Occasionally, the scripts use the interpreter themselves to supply function definitions and other values to the student. More often, the scripts call upon the interpreter only so that the student himself may use it. For reasons discussed below, the scripts have little control over what a student actually does with the UNCL interpreter. After the scripts have suggested a problem and given the interpreter to him, the student may as well be doing his physics homework as the problem suggested by TEACH. Whatever else may be said of this freedom for the student, it presents one serious risk. That is, that the student will blunder into use of a feature which he cannot control (e.g. he will blunder into transfers of control before he understands the procedure for interrupting an infinite loop). To eliminate this risk, the scripts are able to communicate with the syntax scanner of the UNCL interpreter. In particular, the scanner will not recognize any construction which the scripts have not already discussed. In effect, a student is limited to making simple mistakes where the word simple is moving as fast as he moves, but no faster. The scripts engage in limited dialogue with students. Using this capability, the scripts allow a student to request hints about the suggested problems and to determine whether certain sections should be skipped. This feature, along with miscellaneous general purpose features of AGES, also allows the student to review sections which he had previously skipped, or which, for some reason, he may wish to see again. Extract: The UNCL Interpreter The UNCL Interpreter The UNCL interpreter is highly recursive. At any time during its operation, the current level of recursion is a knowable positive integer. Associated with each reeursion level is a scanning pointer (an Instruction Location Counter) within some linear source of statements for execution--a file, the terminal, or a stored program. The interpreter will return from this level to a lower level if: (1) it executes a RETUI~N statement; or (2) the statement source runs dry (e.g. end-of-file is encountered); or, (3) it executes a GO TO to a location on the lower level. The interpreter will save this level and begin execution on the next higher one if: (1) it executes a call to a user-defined function; or (2) it executes a DO statement; or (3) it detects an error in a filed or stored program. The interpreter accepts arithmetic and Boolean expressions in various contexts. These have quite ordinary syntax in UNCL, with only a few noteworthy features. (1) Like ALGOL and MAD, but unlike FORTRAN, UNCL has distinct notations for (a) subscr] ption of arrays and (b) application of functions. (2) Like MAD, but unlike ALGOL or FORTRAN, UNCL has distinct notations for (a) functions and (b) applications of no-argument functions. In several contexts, the interpreter accepts expressions whose values are character strings of arbitrary length. The conventions and built-in functions for dealing with strings are more-or-less the same as those of PL/1, except that UNCL performs no type-totype conversion. A special key on the terminal is an interrupt button. A depression of the interrupt button~has approximately the effect of an execution error. That is, a message appears and then: (1) if the step being executed was taken from the console, it is simply aborted and lost, whereas (2) if the step being executed was taken from a stored program, it is interrupted and execution on the next higher level is begun, with steps being taken from the console. Identifiers and statement labels in UNCL may be of arbitrary length. Statements of UNCL. SET statements (assignment statements) are used in UNCL to assign values to variables or to array elements. Possible right-hand sides include expressions whose values are numbers, truth-values, strings, or functions. Also, the righthand side may be a function literal, as in or set factorial = function of x local i, f set f = 1 fort = 2byltoxsetf = i*f return f end set factorial = function of n if n SeE 0 return 1 return n * factorial.(n-1) end Finally, SET statements must be used in order to create arrays. TYPE statements are used in UNCL to cause printing at the terminal. A single TYPE statement may specify any number of items for printing. If an item is an expression, it is printed along with a representation of its value. Items which are meta-expressions (e.g. locators of steps in stored programs, file designators, "ALL FUNCTIONS", etc.) cause convenient printing of various sorts. A special item allows examination of the interpreter's Instruction Location Counters for each level of recursion. The RETURN statement was exemplified in the discussion of SET. RETURN need not carry any value back to the caller. The DELETE statement in UNCL allows the student to get rid of unwanted variables, program steps, and files. Also, it is possible to delete recursion levels: RETURN will then skip back over deleted levels. REPLACE statements allow stored programs to be modified. REPLACE statements are often used after an error is detected, while the programs are still in operation. GO TO statements allow ordinary transfers of control. These transfers may be nonlocal; the re cursion level is dropped appropriately. DEMAND statements allow programs to obtain data from the on-line user. An IF statement allows conditional execution of an embedded statement, as in the ALGOL construction if . . . then do . . . . FOR statements allow concise descriptions of iteration. The limit, increment, and variable of iteration in FOR are not bound by FOR, so they may freely be modified by the embedded statement. A simple FOR statement was exemplified in the discussion of SET. DO statements cause the current level of recursion to be saved and execution to begin at the next higher level. Execution continues on this higher level until one of the statements executed is RETURN. There are four varieties of DO, as follows: (1) DO CONSOLE causes the new level of recursion to watch for steps typed at the console. (2) DO BLOCK introduces a few steps followed by END; the whole construction has the effect of begin . . . end in ALGOL. (3) DO FILE causes statements to be taken from a named file. The end of the file will serve as a RETURN if one is not encountered before then. If the file name is "CONSOLE" then DO FILE is the same as DO CONSOLE. Similar adjustments are made to other file-handling statements when the file name "CONSOLE" is used with them. (4) A statement like "DO f" is taken to mean "EVALUATE f.( )" LOCAL statements serve to create new generations of variables. These will be available until the current recursion level is relinquished. Any variable not made LOCAL, either explicitly by LOCAL, or implicitly as the formal parameter of a function, is global. Labels, of course, are always local in the sense of ALGOL. An EVALUATE statement carries an expression to be evaluated. EVALUATE may be used to obtain the side-effects of valueless functions. An EXIT statement causes UNCL to discontinue its operation and to return control to the host system. A NULL statement has no effect; neither has a comment. An EDIT statement may be used to expose any stored program to a context editor of the QED variety [4]. An IN FORMAT statement always has within it (a) an embedded TYPE or WRITE statement, and (b) a reference to a string. The string is interpreted as a picture format of the line(s) to be produced by the TYPE or the WRITE. A READ statement refers (a) to a file name and (b) to a variable or an array element: READ functions like DEMAND, setting the variable or array element to the value of the expression on the next line of the file. A RESET statement deactivates a named file, so that the next READ of this file will get the first line. A WRITE statement names a file and is otherwise like TYPE. The lines which TYPE would have produced on-line are appended to the file, which is created if it did not previously exist. Note that if WRITE produces a file a showing the values of various variables, the effect of "DO FILE a" is just to restore the values of the variables. This is especially useful for variables whose values are functions. TRACE and UNTRACE statements affect the execution of functions named in them. The TRACE/UNTRACE facility closely resembles that of LisP 1.5 [5]. UNCL maintains a count of statements executed between terminal actions. If this count ever exceeds a limit, UNCL detects an interrupt-like error. The limit may be set with a STATEMENT COUNT statement. The REMARK statement allows students to direct arbitrary remarks to the instructors. The REVIEW statement allows students to negotiate with AGES for material they might previously have skipped. Each SHORT statement includes an embedded TYPE or WRITE statement. The effect of the SHORT statement is almost the same as that of the embedded statement. The exception is that lines which would have included an expression and a representation of its value now consist of only the latter. SHORT provides a convenient way to produce files acceptable to READ. in [ACM] CACM 13(03) (Mar 1970) 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 [ACM] CACM 13(03) (Mar 1970) 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 [ACM] CACM 13(03) (Mar 1970) view details |