FOCAL(ID:406/foc001)FOrmula CALculator. - JOSS familyfor FOrmula CALculator. Rick Merrill, DEC, 1969. Interactive, for PDP-5/PDP-8's, a descendant of AID/JOSS. ESIX documentation claims direct competition from DEC kills ESIX as a commercial product Related languages
References: Extract: Preliminary Hypothesis and Goal Preliminary Hypothesis and Goal The computer world is in the midst of a raging debate concerning the relative advantages of big-time time-sharing and the dedicated small computer. This debate includes the time-sharing vs. batch-processing disagreement. Project ASC was borne with the idea that the range of applications for which computers are suited is such as to require more than just one computer or one computer mode. It has been felt that the large computer system is being over sold and the small computer given less attention than it deserves in this debate. Project ASC began with the hypothesis that there are many applications suitable for the small computer and its goal is to discover these applications. Extract: The Computer Facility The Computer Facility The point to be made is that the words "computer facility" as used here do not denote the traditional massive conglomeration of men, equipment, and paper but a small, compact, relatively inexpensive laboratory with a markedly unimpressive and yet work-oriented atmosphere. The Project ASC computer is a basic PDP-8/S digital computer (costing under $10,000) with its standard paper tape-teletype input-output terminal. The computer shares a small room with a desk, standard electrical outlets, a bookcase, a mimeograph machine, an IBM time-sharing console, a handy shoebox for spurious paper tapes, a chalkboard, and a number of chairs varying from one to four. The most important contents of the room turn out to be, in a addition to the computer itself, the chalkboard and the shoe-box, and one chair (not to mention chalk). Extract: Comments On The Programming Language: Focal Comments On The Programming Language: Focal If the success of the project can be attributed to any one thing, it would be FOCAL. The language fulfills the basic requirements of a good programming language. It is easy to learn, possesses powers which can be tapped conveniently at successively higher levels of sophistication and has been designed well for its intended purpose. The FOCAL programming language on the PDP-8 gains much in the way of convenience and efficiency by its implementation in an interpretive system. This allows for unreluctant test for speedy debugging. This debugging capability might be harnessed for broader applications if a FOCAL compiler were written to allow the efficient running of debugged algorithms on the PDP-8 or other machines. It is suggested strongly that there is sufficient evidence to prompt a large scale interpreter-compiler system experiment in various environments (PDP-10 say) to test its effectiveness in increasing programming efficiency. [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 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 THE ABACUS/X LANGUAGE ABACUS/X is a lineal descendent of another language known as ABACUS/10. ABACUS/10 in turn is itself an extension of the FOCAL (FOrmula CALculator) language first implemented by Digital Equipment Corporation. A detailed description of FOCAL may be found in (Digital Equipment Corporation). FOCAL is a paragraph-structured language which is designed to be interpreted and is, in fact, one of very few language translators implemented by pure interpretation. That is, the representation of the program stored in memory is pure, unedited and uncompressed ASCII source text. One implication of this approach to implementation is that the resulting interpreter is very slow. However, a more pertinent implication in the single-user minicomputer environment is that the user has unique capabilities and flexibility when utilizing the system interactively, Some characteristics of the language are: 1. Statement numbers consist of a group number and a line number separated by a period (e.g. 2.12, 14.60, etc.). The group number is used to segregate statements into paragraphs. Paragraphs may be executed by means of the "DO" statement in the same manner as the "PERFORM" verb in COBOL. 2. The object of the '~GOTO" and ~:DO" statements may be an arbitrary expression. Such expressions are evaluated at run time and the resulting value regarded as the target line or group number. 3. Individual lines or groups of lines may be deleted from a program either while in console command mode or dynamically while running. 4. Placing a "?" in a program statement activates a trace facility which outputs the ASCII source program statements on the console (or other output device) as they are interpreted. 5. There is no need to dimension arrays since, from FOCAL's viewpoint, a subscripted variable is merely a long variable name and is allocated when it is first referenced. That is, if A(4), A(2000), and A(38) were referenced in a program, space for only three variables would be allocated, not an entire array. FOCAL as originally implemented is unsatisfactory for business applications and, of course, runs only on DEC machines. ABACUS/IO is an extension of FOCAL implemented for Data General Nova computers with added facilities to adapt it for business applications. Among the features added are: support for a variety of disk drives, cassettes, floppy disks, printers and other peripherals. It is possible to chain programs together so one program can load another and initiate the new program's execution without user intervention. It is also possible to do dynamic program overlays on a line-by-line basis. ABACUS/10 has two disadvantages, however, which limit its usefulness. First, it is so slow that its viability becomes marginal in situations where computation is significant or large volumes of data must be processed. Second, its character handling ability may be charitably described as minimal. These defects made it essential to seek a replacement. In designing this replacement we were presented with several criteria: The resulting language was to be as compatible as possible with the original ABACUS/10, ~since there was already a substantial investment in programming; and retraining was to be minimized. Second, the new language was to have powerful character manipulation facilities. Third, the system was to retain all the flexibility of the ABACUS/10 interpreter. Finally, the system was to provide execution speeds comparable to that of compilers. The resulting translator was the incremental compiler ABACUS/X. This language is a superset of the old ABACUS/IO with the addition of the following features: 1. String variables like those in BASIC, including substrings, concatenation, literals, assignment statements, etc. 2. Input/output formatting similar to that in FORTRAN. 3. The integer data type is supported (ABACUS/IO has only reals). Also, double precision reals can be utilized if deslred 4. Logical IF statement (ABACUS/IO has only an arithmetic IF). 5. Encode/decode facility for converting strings to numerics and vice versa. 6. Genuine arrays created by dimension statements with generalized subscript bounds. 7. The I/O structure is far more elaborate than ABACUS/10's. Full access to operating system facilities is provided. Alternate versions exist which run under three different operating systems. 8. The machine code emitted by ABACUS/X is comparable to that produced by FORTRAN IV in both size and execution speed. Besides providing these significant extensions, the ABACUS/X language retains the full flexibility and convenience of its interpretive predecessor. Extract: INTRODUCTION INTRODUCTION Enduring the language translation process in a typical minicomputer environment can be a painfully time-consuming and frustrating experience. The low speed, low cost peripherals usually associated with a minicomputer (console teletype, paper tape reader/punch, magnetic tape cassette unit) are certainly not the translator writer's first choice to meet his input/output needs. Moreover, the seemingly innocent requirement for multiple passes over the source program has unfortunate implications in such an environment. Rewinding a cassette tape seems to take hours, and the message "Reload paper tape source program for second pass" has awakened many users to the fact that many translators do indeed read through the source program more than once. Today most computer programming is done through the use of a high level language for algorithm expression. The advantages of this method, including easier program development and more maintainable programs, are well known. In order for the computer to be able to use the program, however, it must first translate the high level language of the program into something meaningful to itself. Probably the most popular technique for accomplishing this translation is through the use of a compilers which generates the machine language equivalent of the high level language program. In the minicomputer environment, the source program is typically entered via a text editor~ and the resultant character string is then fed to the compiler one or more times to generate the hopefully usable object program. All errors lead one back to the editor for corrections to the source program, where another complete copy of the program is produced. The process is then repeated until either the prope K results have been obtained, or the user gives up from frustration or lack of more paper tape, Compiler object code is executed directly by the machine, and thus is very efficient in terms of execution time. Also, once the program works properly, the object code may be saved, thus eliminating the need for any more compilations. However, if even just one statement needs to be changed, the entire program must be recompiled. Also run time diagnostics tend to be difficult to interpret, due to the fact that there is usually no information maintained correlating the source statements with the resultant object code. Another popular technique for high level language translation involves the use of an interpreter, which scans a source state,cent (or some internalized form of it) each time the statement is to be executed in order to determine what actions are to be taken. An interpreter typically has a built-in editor, thus the source program is entered directly into the interpreter, usually with some amount of syntax checking being done at this time. Any source language errors detected here may be corrected by simply reentering the statement properly. When the entire program has been entered, issuance of a '~RUN' command starts program execution. Errors detected at run time are corrected by forcing the interpreter back to text entry mode, and changing the appropriate program statements to eliminate the error(s). Since the program exists in source language form, changing a single statement causes no retranslation problems, and interpreters are able to give excellent run time diagnostics. However, the interpreter must translate a program statement each time before its use, resulting in much slower execution speeds than when using compiled object code. A third, less popular technique for high level language translation involves the use of an incremental compiler, which generates the machine language equivalent of each source statement as it is entered into the system. The translation is performed on a statement-by-statement basis, rather than on the entire program at once, thus the term "incremental" compilation (See Katzan, 1969 for an excellent discussion of the incremental compilation process.). Source program entry is accomplished much as with an interpreter. Source statement errors are detected and diagnostics produced immediately upon entry of the offending statement. Corrections may be made by reentering the source line properly. Statements are compiled into object code if no source errors are detected, with appropriate links maintained for inter-statement references. Since the object code is generated as the program is entered, when the "RUN" command is issued for execution only inter-statement references need be fixed~up before execution of the complete machine language 6bject program can begin. The object code is directly executable by the machine, and thus is very efficient in terms of execution time, Also, most incremental compilers allow one to save working object code, thus eliminating the need for more compilations. If changes are to be made, however, only the statements affected need to be recompiled. This is accomplished by simply reentering the appropriate source statements. An incremental compiler is ideal for the interactive minicomputer environment, giving immediate source language diagnostics and taking the place of a text editor, while making program changes and corrections easy and fast. However, an incremental compiler may force certain restrictions on the high level language and its users. These restrictions, although not aesthetically pleasing to the purist, are generally of a minor nature, particularly when one considers the benefits gained. Probably the biggest disadvantage of an incremental compiler system is the amount of main memory residence required. In a minicomputer environment this is, of course, a major problem. In this paper we describe an incremental compiler that has been developed for Abacus Corporation, Detroit, Michigan, which takes advantage of the positive aspects of incremental compilers, while minimizing the negative aspects, as will be described herein. The compiler was implemented for the Data General Nova minicomputers (Data General Corporation), and is currently being used in a commercial turnkey system development environment. in SIGPLAN Notices 11(05) (May 1976) view details in SIGPLAN Notices 11(04) April 1976 view details in SIGPLAN Notices 11(04) April 1976 view details The PDP-8 Educational Simulations. In 1969 when I joined DEC there really wasn't an educational market. The PDP-8s spoke machine language and FOCAL, an interactive language modelled on ALGOL [SIC!!] written at DEC by Rick Merrill. It was a very interesting and powerful language that, in hindsight, could have been the generic language if DEC had made it widely available. Then BASIC would not have had a chance. Rick Merrill also developed some simulation games - which is what interacting with a computer is all about. In one of these, Hammurabi, students manage a little city-state where they buy and sell land, feed their subjects, protect grain warehouses from rats, save grain for planting next year's crop, and deal with lots of little interacting variables. We fit both FOCAL and the program into the 4K memory available on the PDP-8. The original program was about 700 bytes. Since the world was not beating a path to DEC's door to buy FOCAL machines, we contracted with others to write BASIC for the PDP-8. in SIGPLAN Notices 11(04) April 1976 view details History NODAL was designed in the beginning 70's at CERN in Geneva as a flexible and easy to handle tool for controlling the SPS accelerator. In NODAL features of FOCAL and SNOBOL-4 (with some influence of BASIC) are combined. The first implementation was written in assembler for the NORD-10 minicomputer, now an assembler version for the NORD-100 exists too. Many of these computers are interconnected in a homogeneous network. Each of these nodes may be used to execute NODAL programs whereby exchange of NODAL statements and NODAL data between the different computers is possible. In the control of the new accelerator LEP other processors than for the SPS are used for which the existing assembler implementations of NODAL cannot be adapted easily. Since NODAL was found to be very useful at testing, during running-in and in all situations where flexible response was required, it was desirable to have NODAL also available for LEP. To overcome the limitations of assembler programs when adapting them to different processors it was decided to create a new version, written in a portable language. The choice was MODULA-2, since for this language compilers are available for all computers used. When designing the control system for the new GSI accelerators, the Prozessrechnergruppe was looking for an interpreter for accelerator control. Because of the portability of the new NODAL version it was decided to cooperate with CERN and use NODAL also at GSI. Extract: Characteristics of NODAL Characteristics of NODAL Contrary to other interpreters NODAL is emphasized by the following characteristics: integrated elements for access to equipment, called data-modules. parts of programs can be exported to run on another computer and results of calculations can be received (not implemented in GSI-version). output of programs and data to files (and also to other computers) is formatted uniformly. Thus it is possible to store programs and data in one file. Special features of the MODULA-2 version of NODAL are: The separation into kernel modules (processor independent) and target modules (processor dependent) eases the adaptation to different types of processors. When transferring NODAL to another processor, only the target modules like file input/output, error handling, operating system access etc. have to be modified. Actually modules exist (or are under work) for MC68000, VAX/VMS, VAX/UNIX, NORD-100, LILITH, TMS9900, IBM-PC. Execution is faster than in the previous assembler versions. This is achieved by generating an intermediate code which is used after first execution of a program. Thus lexical and syntax analysis has to be done only once which speeds up repitative parts of NODAL programs. To calculate arithmetic expressions it is planned to install a 'throw-away' compiler. pdf in SIGPLAN Notices 11(04) April 1976 view details Resources
|