CORC(ID:180/cor010)
CORnell Compiler
CORnell Compiler. Simple language for student math problems.
Places
Related languages
| ALGOL 58 | => | CORC | Mild Influence | |
| FORTRAN IV | => | CORC | Mild Influence | |
| CORC | => | BASIC | Slight Influence | |
| CORC | => | CLP | Extension of | |
| CORC | => | CUPL | Influence | |
| CORC | => | PUFFT | Influence |
Samples:
References:
The CORC Language
We sought a language with which a usable facility for simple problems could be taught as rapidly as possible and which could be readily recalled to service after considerable periods of disuse. This clearly required a language with simple structure, few rules and special conventions, and a high degree of compatibility with common English and algebraic usage. We began by examining our experience in teaching Algol and Fortran to determine just what topics took the most time and provided the most difficulty. Secondly, we attempted to summarize and characterize the mistakes most frequently encountered in student programs written in these languages.
We translated our general criteria into a set of specific design rules:
1. There should be as few different types of statements as possible.
2. All statements should be executable-?there should be no compiler-controlling declarations.
3. Ordinary decimal numbers should be used. There should be no explicit distinction between numbers with and without a decimal point.
4. Special programming forms would be used which would be highly restrictive, but largely self-explanatory. Their layout and labelling could reduce the number of rules and restrictions that would have to be elsewhere stated.
5. There should be few rules, and even fewer exceptions. In considering where teaching time is spent it is clearly evident that the trouble spots are in input-output and the treatment of subroutines. The input-output problem was quickly "solved" by specifying a rigid format. Input is by a read statement which simply lists the variables to be provided with values. The data is provided, one word per card with format dearly indicated on a special printed form. Output is by means of a write statement in which the desired variables are listed. The names and values of these variables are displayed in a standard format, easily read by someone who has never seen the particular program or heard of CORC or a computer. A title statement allows the programmer to further label his results.
The treatment of subroutines was the subject of much deliberation and the solution represents probably the most unique aspect of CORC. It offers significant simplification compared to other algorithmic languages, but concomitant limitation in power. The solution is the concept of a "repeatable block" of statements. In simple and restrictive manner this provides the basic iteration statement of the language (corresponding to Fortran's do statement) as well as the subroutine or procedure. A sequence of statements is identified as a "block" by being preceded by a begin statement and followed by an end statement. The begin and end are clearly related to each other by bearing identical labels. These blocks are properly closed subroutines. They can be located anywhere in the program and one cannot "fall into" a block by encountering its begin statement in the normal sequential execution of the program. (The program would continue with the statement following the block end just as if the block did not exist.) The block may be entered only by means of a repeat statement which has one of three forms:
REPEAT block-label E
TIMES REPEAT block-label
UNTIL EloE2
REPEAT block-label
FOR V = E1 , E2, ¦ ¦
where E is an arithmetic expression, p is a relational operator and V is a variable. The block need not be contiguous to the repeat statement-?many repeat statements may refer to the same block. In each case the identity and limits of the block are evident from the labelling. This admittedly requires more writing than Algol or Fortran, particularly for cases where the blocks are short and directly following the controlling statement, but the simplicity of rules and the clarity with which a strange program can be followed are more than sufficient compensation.
The blocks provide a rudimentary subroutine ability. The programmer is spared the relatively difficult concept of a dummy variable (and of course denied the power of the concept) as all variables are free and open to the entire program. A one-variable subroutine may be effected by using the repeat . . . for statement to substitute a variable with the reservation that the "dummy" variable cannot be carelessly duplicated elsewhere in the program.
We believe that complex subroutine structures are infrequently encountered in the type of service for which CORC is intended. When they are encountered they represent a tremendous source of confusion and error and the neophyte might be better off with the tedious but straightforward CORC procedure.
All numbers will be carried in floating point form in the program, truncated to word length as necessary. (Our truncation points are different in the 10-digit 220 and the 48-bit 1604.) The programmer may use integers and decimals as in common practice without special convention or distinction.
CORC provides for subscripted variables, with a maximum of two subscripts, but with an unlimited number of levels. (Expressions including subscripted variables may appear in subscripts.) Desirous of eliminating the "array" or "dimension" declaration, and being unwilling to specify a standard dimension we make a virtue out of necessity and require a "preliminary dictionary of variables." All variables to be used-?not just those with subscripts-? nmst be listed on a special printed form. A space for dimension declaration is provided and initial values may also be given. While an experienced programmer would certainly regard this as an unnecessary and onerous burden it is a ve~T worthwhile discipline for a beginner. (This dictionary also allows some interesting opportunities in the compiler, which will be discussed below.)
The assignment statement is conventional except for the prefatory word LET; i.e. LET X = Y. The word LET emphasizes the fact that the statement is a command and not an equation, and it permits a rule without exception that every statement starts with a "reserved" word. It also provides a measure of redundancy that is used to good advantage in the compiler. The IF statement is a two-way branch on a true or false condition:
IF ElpE2
THEN GO TO label 1 ELSE GO TO label 2
In summary, the language consists of just nine types of statements (written one to a line, with FORTRAN-type continuation):
LET
GOTO
IF
REPEAT (BEGIN, END)
READ
WRITE
TITLE
NOTE (program comment)
STOP
Although a long and complete manual is available and used for initial presentation, the rules for the language can be succinctly but completely written on one page, and in fact are printed on the reverse side of one of the programruing forms.
Extract: A field test of CORC
A field test of CORC
CORC has been operating at the Cornell Computing Center since September, 1962. A procedure is used in which students deposit their programs at the Center, written on the special CORC forms. The personnel of the Computing Center key-punch the programs (without verification) and make the initial computer run. Card decks, original programs and computer output are then returned to the students in a large work room where card files, work tables, desk calculators, and key punches are provided. The students are responsible for making corrections in the card decks as necessa~T and placing these in a re-run drawer. The work is handled on a first-come-first-served basis and no attempt is made to segregate the problems by course. Except for a few times when the key-punching load peaked drastically a 24 hour turnaround time has been provided. Often a program submitted before 9 AM would be ready in late afternoon.
As of this writing almost 4000 programs have been submitted by more than 300 students in 20 different courses. The average number of passes to achieve acceptable operation is slightly more than two (somewhat more than 4000 reruns have been submitted). Equally significant, about half of the programs ran acceptably on the first pass. In interpreting these results one should bear in mind that for the majority of these students, instruction in CORC was an incidental inclusion in a mathematics or engineering course and that the instructor was simultaneously experiencing his first contact with automatic computation. In addition some reruns were occasioned by key-punching errors that were no fault of the students', and during the first weeks of operation reruns were occasionally required fox" programs that revealed residual faults in the compiler.
On the whole the language and the operating system have been most satisfactory. Students, faculty and the Computing Center seem satisfied with the performance. We expect to put the present system into full-scale service next Fall, which will involve about 1000 new programmers each year, with a total of perhaps 3000 students making intermittent use of the system. This would provide an average load of 150-200 programs per day.
We are aware that Fortran and Algol can be taught to large numbers of students in relatively short periods of time and can be used in a closed-shop operation such as the one we have described. Cornell has used the Burroughs Algol extensively in this manner in prior years. We are also aware that there are pedagogical techniques such as programmed learning and filmed lectures which can make this instruction efficient and economical. But we are entirely convinced that given the same competence of instructor and students and comparable instructional methods a CORC-like language can be significantly more rapidly taught and learned than Fortran or Algol and is a much more practical computing vehicle for the occasional programmer.
Although changes in the source language may be made from time to time we intend to resist the pressures and temptations to snake seemingly innocent additions which could in time erode the basic objective of the project. The implementing compilers are a different story altogether and we hope to see them undergo continual improvement. In particular we believe that much more elaborate and effective error-correction than we currently provide can be practically accomplished.
We confidently expect that CORC will be used at Cornell for some years to come. We are willing to export the language but we do not intend to measure the success of the project by the number of other centers which adopt its use. CORC was constructed to serve a practical and local need at Cornell and to prove a point: it is possible to construct a language and a compiler that will make some of the benefit of automatic computation more readily available to an unskilled programmer by shifting more of the burden of the process onto the computer. CORC is only a start in this direction and we expect that others, more knowledgeable of the computing art than we, will produce systems which serve these goals much better. We think it is clear that a single algorithmic language will not adequately serve the needs of both professional and amateur programmers. Once this proposition is accepted and compromise solutions abandoned both groups can take better advantage of the computing power that is available today.
in [ACM] CACM 6(06) (June 1963) view details
in [ACM] CACM 6(06) (June 1963) view details
Cornell has written CORC compilers for the Burroughs B220 and the Control Data 1604. The compilers are designed to provide extensive diagnostic help during compilation and execution. Error messages during execution include the type of error and the sequence number of the offending source language statement. When an error is detected during compilation or execution, corrective action (usually, substitution of a harmless alternative for the erroneous construct) is taken, and compilation or execution continues to allow the remainder of the program to be tested.
in ACM Computing Reviews 4(06) November-December 1963 view details
I. Introduction
CORC, the Cornell Computing Language, is an experimental compiler language developed at Cornell University. Although derived from FORTRAN and ALGOL, CORC has a radically simpler syntax than either of these, since it was designed to serve university students and faculty. Indeed, most of the users of CORC are "laymen programmers," who intermittently write small programs to solve scientific problems. Their programs contain many errors, as often chargeable to fundamental misunderstandings of the syntax as to "mechanical errors." A major objective of CORC is to reduce the volume of these errors. This objective has been achieved to the following extent: the average rate of re-runs for 4500 programs submitted during the fall semester of 1962 was less than 1.1 re-runs/program.
Three features of CORC have enabled it to achieve this low re-run rate:
(1) Inherent simplicity of the syntax;
(2) Closed-shop operation of the Cornell Computing Center on CORC programs, including keypunching, machine operation, and submission/return of card decks;
(3) A novel and extensive set of error-correction procedures in the CORC compiler/monitors.
The CORC language is briefly described below; it is more fully documented elsewhere.1
The current paper describes the error-correction procedures in greater detail.
Extract: The CORC Language
II The CORC Language
CORC was designed by a group of faculty and students in the Department of Industrial Engineering and Operations Research at Cornell. This group has coded and tested two similar compiler/monitor systems, one for a medium scale decimal computer and the other for a large binary computer.
During the definition of the language, the design group surrendered potency to simplicity whenever the choice arose. Certain redundancies have been included in CORC, serving two functions: to facilitate error-correction during source-deck scanning, and to aid novice programmers' grasp of compiler-language syntax. Excepting these redundancies, CORC is quite frugal with conventions. For example, all variables and arithmetic expressions are carried in floating-point form, avoiding the confusing notion of "mode." At the same time, programmers are spared all knowledge of floating-point arithmetic.
Each CORC card deck is divided into three required sub-decks plus an optional sub-deck of data cards:
(a) The preliminary-description cards supply heading data for each page of the output listing.
(b) The dictionary cards declare all variables used in the program, simple as well as subscripted.
(c) Each statement card may have an indefinite number of continuation cards. Statements may bear labels having the same formation rules as variables. Continuation cards may not be labelled.
Variables, labels, numbers, reserved words, and special characters comprise the symbols of CORC. Each symbol is a certain string of at most eight, non-blank characters. Numbers may have up to twelve digits; decimal points may be leading, trailing, or imbedded in the numbers, There are forty-three reserved words in CORC, e.g., LET, and ten special characters: + ? */$ = ( ) ., The character string defining each label, variable, or reserved word is terminated by the first blank space or special character. The character string defining each number is terminated by the first character that is neither a digit nor a decimal point. Each special character is a distinct symbol. There are forty-six legal characters in CORC: letters, digits, and special characters,
A subset of the reserved words is the set of fifteen first-words: LET, INCREASE, INC, DECREASE, DEC, GO, STOP, IF, REPEAT, READ, WRITE, TITLE, NOTE, BEGIN, and END. The first symbol in each statement should, if correct, be one of these first-words.
There are eight executable-statement types, plus a NOTE statement for editorial comments on the source-program listing. (NOTE statements may be labelled; in this ease, they are compiled like FORTRAN "CONTINUE" statements.) To simplify the description of the statement types, single letters denote entities of the CORC language:
V ......a variable, simple or subscripted
E ......an arithmetic expression, as defined in FORTRAN
L ......a statement label
B ......a repeatable-block label (see below)
R ......one of the six relational operators:
EQL, NEQ, LSS, LEQ, GTR, and GEQ. A relational expression is a predicate comprising two arith-
metic expressions separated by a relational operator, e.g., 2*X NEQ 0.9.
The statement types are as follows:
(1) LET V = E, and two variants INCREASE V BY E and DECREASE V BY E. (INCREASE may be abbreviated to INC, DECREASE to DEC.)
(2) IF E, R Ea
THEN GO TO L,
ELSE GO TO h.,, and two variants
1FE,, R, B,a IF En R, E,a
AND E,, Rs E,= OR ES1 R2 E.*
AND Bsi Rx Bm OR E» Bs EK2
THEN GO TO L, THEN GO TO L,
ELSE GO TO L. ELSE GO TO L2.
(3) GO TO L.
(4) STOP, terminating execution of a program.
(5) READ V,, V5,. .., bringing in data cards during the execution phase. Each data card bears a single new value for the corresponding variable.
(6) WRITE V,, V,, . . ., printing out the variable names, the numerical values of their subscripts for each execution of the WRITE statement, and the numerical values of these variables.
(7) TITLE (message), printing out the remainder of the card and the entire statement fields of any continuation cards.
(8) REPEAT B . . ., comprising four variants
(8a) REPEAT B E TIMES,
(8b) REPEAT B UNTIL Eu Rt B«
AND ES1 R2 BH
AND Ex, RK EM,
(8c) REPEAT B UNTIL En R, KM
OR E» R2 Eaa
OR
(8d) REPEAT B FOR V = E,, E2.....
E,, Ej, Et).....where (E,, E,, Ek)
is an iteration triple as in ALGOL.
Closed subroutines?called repeatable blocks in CORC?are denned by two pseudo-statements as follows:
B BEGIN
B END,
where the "B" labels appear in the normal label field. A repeatable block can be inserted anywhere in the sub-deck of statement cards; its physical location has no influence on its usage. It can only be entered under control of a REPEAT statement (with a few erroneous-usage exceptions).
Repeatable blocks may be nested to any reasonable depth. Any number of REPEAT statements can call the same block, although the blocks have no dummy-variable calling sequences. All CORC variables are "free variables" in the logical sense, which avoids confusing the novice programmer no less than it hampers the expert programmer.
in [AFIPS JCC 26] Proceedings of the 1964 Fall Joint Computer Conference FJCC 1964 view details
Several quite different approaches to languages and systems for student Jobs have been used at various Universities. In one approach a very simple and basic computer language is used. CORC at Cornell is an example. The idea is to get the student on the computer rapidly and easily. Presumably the students can transfer the knowledge gained to other more complex languages when necessary.
in Proceedings of the 19th ACM national conference January 1964 view details
Presented in this paper are the highlights of CLP, a teaching language which has been employed at Cornell University and was constucted to serve as a means of introducing simulation and other list-processing concepts. The various advantages of CLP are discussed and examples are given.
List processing is a convenient mode of description for many of the more interesting and provocative areas of computer application, but the available languages--such as IPL-V, COMIT, LISP, SIMSCRIPT--require a level of programmer sophistication that makes them ahnost prohibitive for normal classroom use. CLP was constructed to see if some of the power of the list-processing concept could not be made available in a language that requires no more than a "FORTRAN level" of sophistication. CLP was superimposed upon a locally developed language called CORC. This is a general algebraic language, now taught to all engineering undergraduates at Cornell and many students in other colleges of the University. It is a simple source language, implemented by compilers (Control Data 1604 and Burroughs 220) that attempt much more than the usual level of error detection and error correction. The result has been a considerable reduction in the average number of machine approaches required to achieve successful execution, as compared to previous experience with BALGOL and FORTRAN. Through batch processing with a special operating system there has been a considerable reduction in the machine time required for compilation and execution as compared to FORTRAN.
After introductory experience with CORC some students find it necessary, and not difficult to progress to FORTRAN for major computational projects. The intent of CLP was to provide a comparable path of graduation for students who were interested in essentially non-nmnerieal computation.
CORC is entirely included in CLP; the CLP compiler for the 1604 will process CoRc programs without modification. The basic CORC statements are given below.
In CLP a number of additions were included that have nothing to do with list processing but which relax some of the inflexibility of basic CoRe. These include access to magnetic tape auxiliary storage, a "computed GO TO" statement, compound statements (in the ALGOL sense), and a very flexible Report Generator to specify variable output format, patterned after the generator of the SIMSCRIPT language [2]. In some cases CLP is used simply for the benefit of one of these extentions. The real purpose of the language, however, is served by the introduction of a new kind of data element, and an additional set of statements for their processing. In addition to the usual variables, vectors and matrices, the programmer can declare, by name, his intention to use a particular kind of "entity" in the program. An "entity" is a particular kind of data record, as defined in the declaration, such that (a) the number of a given kind of entity of interest will vary from time to time during execution, and (b) the set of entities may be dynamically partitioned into various different subsets, called lists.
Extract: Example - Car
For example, for a program intended to simulate detailed vehicular flow in a certain street network one might declare an entity named CAR. A CAR would be described by a number of "attributes," such as possibly SPEED, DIRECTION, LENGTH, ACCELERATION, POSITION, and each CAR would be represented by a record containing a data word for a value for each attribute. In effect, the attributes are simply variables with the entities providing an unusual manner of subscripting. The progrmnmer writes DIRECTION OF CAR(I) to identify one particular value out of the many DIRECTION variables that may exist at the moment. The entire phrase DIRECTION OF CAR(I) is used exactly as a normal algebraic variable in any of the regular CoRe statements as well as the added CLP statements. During the course of computation entities may either enter or depart from the sphere of interest. The programmer uses the statements
LET I = NEW CAR
and
ERASE CAR(J)
to accomplish this.
The former creates a new entity CAR in the sense that a block of the required size is removed from available storage, assigned to be a CAR, and the variable I receives the value of an identification number for this CAR. ERASE CAR(J) simply releases the record previously assigned to CAR(J) for reassignment. The whole point of this dynamic assigmnent of storage is that the total number of cars which might be considered at some time during the execution of the program is potentially beyond the storage limits of the computer, and this scheme allows the records for new arrivals to overlay the records for cars which are no longer of interest. This can of course be accomplished by programming in a general algebraic language, but it is convenient to have it done automatically by the compiler.
It is also convenient to be able to associate groups of CARs by their position, their drivers' intentions, their velocity, or any other characteristic that might be of interest or use to the processing routines of the program. These groupings are called lists and during the course of execution entities may be placed on lists by the statements:
INSERT CAR(I) FIRST ON LANE(K)
INSERT CAR(G q- 2) AFTER CAR(P) ON INTERSECTION(
NORTH)
INSERT CAR(M) BEFORE CAR(N) ON PARKROW(S)
INSERT CAR(H) LAST ON REPAIR
A particular entity can, of course, be on several different lists at the same time. (Actually the list consists of a set of names of entities, rather than the entities themselves, and these names can be used as often as required.) If desired, the arrangement on a list can be in order of the value of a particular attribute of the entities on the list. For example, a list called LANE might be declared to consist of CARs ranked by the value of the CAR's attribute POSITION. A CAR would be placed on the list during execution by the statement:
INSERT CAR(I) RANKED ON LANE
Similarly entities can be removed from lists as their status changes during execution:
REMOVE CAR(I) FROM LANE
Ordinarily this statement is preceded by another that determines the identification number of the entity to be removed:
LET I = CAR FIRST ON LANE
REMOVE CAR(I) FROM LANE
LET X = CAR LAST ON LANE
REMOVE CAR(X) FROM LANE
LET X = CAR BEFORE CAR(Q) ON LANE
REMOVE CAR(X) FROM LANE
LET DELETE = CAR AFTER CAR(HALT) ON LANE
REMOVE CAR(DELETE) FROM LANE
One can index the execution of the CORC REPEAT statement over all of the entities that exist at the moment of encounter:
REPEAT ADVANCE FOR ALL CAR(I)
(where I is then the indexing variable in the program block labeled ADVANCE) or over all of the entities that are on a particular list:
REPEAT PARK FOR ALL CAR(X3) ON WAIT
Extract: CLP and the CORC philosophy
The CLP compiler continues the CORC philosophy of providing extensive error detection, attempts at error correction, and a guarantee of reaching execution regardless of the state of the program. All of the Conc monitoring is present, as well as additional tests appropriate for the additional statements and data elements of CLP. CLP's debt to SIMSCRIPT is obvious and is readily acknowledged.
In fact, the decision to define and implement CLP grew out of a semester's experience in teaching SIMSCRIPT in a graduate course in simulation. So much time was spent on instruction in the language that other material was neglected. In comparison CLP will not accommodate as large a problem as SIMSCRIPT for although the memory of the 1604 is as large as the 7090-94 it is not used as efficiently (no partial-word packing) and the compiler remains in core during execution. (This is not logically necessary, but it was convenient and expedites batch processing of student programs. The available space for obiect program has always been sufficient.)
Execution is somewhat faster, and compilation is much faster than SIMSCRIPT. Although the programmer must construct his own timing routine for a simulation, and occasional circumlocutions are necessary as compared to SIMSCmPT'S flexible and powerful statements, in general CLP is a much easier language to use.
However, CLP was intended for a very specific purpose and not as a general alternative to SIMSCRIPT. As a vehicle to introduce the concepts of simulation and list processing, and as a means of implementing the relatively small problems that are characteristic of student investigations it has been most successful. It has been used rather extensively in the last year at Cornell and the results have been very encore-aging. Students have been able to write programs for sinmlations, adaptive and heuristic gameplaying routines and other pseudointellectual processes as regular course assignments that would previously have been considered to be of scope appropriate for a thesis.
in [ACM] CACM 8(04) April 1965 view details
An important step in artificial language development centered around the
idea that i t is desirable to be able to exchange computer programs between
different computer labs or at least between programmers on a universal level.
In 1958, after much work, a committee representing an active European computer
organization, GAMM, and a United States computer organization, ACNI,
published a report (updated two years later) on an algebraic language called
ALGOL. The language was designed to be a vehicle for expressing the processes
of scientific and engineering calculations of numerical analysis. Equal stress was
placed on man-to-man and man-to-machine communication. It attempts to
specify a language which included those features of algebraic languages on
which it was reasonable to expect a wide range of agreement, and to obtain a
language that is technically sound. In this respect, ALGOL Set an important
precedent in language definition by presenting a rigorous definition of its syntax.
ALGOL compilers have also been written for many different computers.
It is very popular among university and mathematically oriented computer
people especially in Western Europe. For some time in the United States, it will
remain second to FORTRAN, with FORTRAN becoming more and more like
ALGOL.
The largest user of data-processing equipment is the United States Government.
Prodded in Part by a recognition of the tremendous programming investment
and in part by the suggestion that a common language would result only
if an active Sponsor supported it, the Defense Department brought together
representatives of the major manufacturers and Users of data-processing equipment
to discuss the problems associated with the lack of standard programming
languages in the data processing area. This was the start of the conference on
Data Systems Languages that went on to produce COBOL, the common business-
oriented language. COBOL is a subset of normal English suitable for expressing
the solution to business data processing problems. The language is
now implemented in various forms on every commercial computer.
In addition to popular languages like FORTRAN and ALGOL, we have
some languages used perhaps by only one computing group such as FLOCO,
IVY, MADCAP and COLASL; languages intended for student problems, a
sophisticated one like MAD, others like BALGOL, CORC, PUFFT and various
versions of university implemented ALGOL compilers; business languages in addition
to COBOL like FACT, COMTRAN and UNICODE; assembly (machine)
languages for every computer such as FAP, TAC, USE, COMPASS; languages to simplify problem solving in "artificial intelligence," such as the so-called list
processing languages IPL V, LISP 1.5, SLIP and a more recent one NU SPEAK;
string manipulation languages to simplify the manipulation of symbols rather
than numeric data like COMIT, SHADOW and SNOBOL; languages for
command and control problems like JOVIAL and NELIAC; languages to simplify
doing symbolic algebra by computer such as ALPAK and FORMAC;
a proposed new programming language tentatively titled NPL; and many,
many, more. A veritable tower of BABEL!
in [ACM] CACM 8(04) April 1965 view details
in [ACM] CACM 9(10) October 1966 view details
I. Introduction
Much of the attention given to compiling techniques for algebraic languages has been directed toward producing more efficient object code. automating the process of writing a compiler, and incorporating new features into the programming source languages. An area which has not received comparable emphasis is that of developing techniques to improve the diagnostic capabilities of compilers. This lack of emphasis may be in part due to the fact that the usual specifications of a programming language exclude or give little attention to the need of diagnostic capabilities, for example, the specification of ASA Basic FORTRAN or ASA FORTRAN (see [1]). In this paper CSC is described--the results of a compiler project undertaken at the University of Wisconsin Computing Center (UWCC).
DITRAN (Diagnostic FORTRAN) is a FORTRAN compiler and operating system which provides extended diagnostic capabilities, both at compilation and execution time. One of the purposes in presenting this paper is to outline some of the design features of DITRAN which, when combined with some known algebraic compiling techniques, make it possible to achieve a high degree of success in the detection and analysis of compile time and execution time errors.
DITRAN achieves many of its diagnostic capabilities by extending the notion of a storage unit by associating with each unit a vector of values which describes the status of a variable or array element during the execution of a program. Another purpose of this paper is to discuss, in general, some of the standards or objectives that ought to be set for the diagnostic capabilities of any compiler. DITRAN was written for the CDC 1604 and was put into operation at the UWCC in the summer of 1965.
DITRAN has now received considerable use and the success with DITRAN supports the belief that more attention to this area of compiler development can provide worthwhile dividends. Although DITRAN operates as a compile-and-go batch processing system, many of the techniques employed to maintain information required for diagnostic capabilities ought to be of particular use in an interactive environment involving man and computer via an inputoutput device.
Extract: Background and Objectives
II. Background and Objectives
Manufacturer-supplied FORTRAN compilers normally provide rather efficient object code, provide flexible interaction with the operating systems, and have many sophisticated programming features. However, they are inadequate for the needs presented in the area of finding and correcting errors as quickly as possible. In many instances, the description of an error condition lacks resolution and offers the user little assistance in removing the error other than indicating the statement in which the error occurs. A more serious inadequacy is that many error descriptions are given in terms not understandable to a FORTRAN programmer. For example, (1) several types of compilation time errors are passed on to the assembly phase and emerge as assembly errors which are quite often difficult for the user to associate with his source program, or (2) execution time errors are presented in terms of absolute or relative core locations and machine instructions, all of which are of little or no value to the FORTRAN programmer. Perhaps the most serious inadequacy of the compilers is the inability to detect some error conditions.
These conditions are prohibited by FORTRAN manuals, but the compilers produce no messages for these errors. At execution time, these errors produce undefined results usually dependent upon the residual contents of storage locations of which the programmer is unaware and over which he has no control, for example, subscripting beyond the limits of an array, accessing an entity which has not been assigned a value, or performing real arithmetic on type integer data assigned to a type real entity through an I/O operation or through equivalence associations.
In a university, a large portion of the users of a computing facility are students learning programming and graduate students or research investigators who are not full-time programmers but are faced with the need of using the computer as an educational or research tool. For this group, in particular, the concern of finding and correcting errors in their programs as quickly as possible outweighs the need for efficient object code and sophisticated protramming features. Programs submitted by this group generally involve a rather small amount of computer run time and have rather short useful lives. The ratio of machine time used for program checkout to that used for production is quite high. The interests of this group of users presented a need for a compiler which would provide a maximum of diagnostic information to the progrannner in order to shorten the checkout time.
DITRAN was developed to provide a compiler with extensive diagnostic capabilities. It appeared that developing this compiler would increase the service of the computing facility in several areas. By providing more complete diagnostic information on all errors encountered, the compiler would aid in reducing the number of runs required to check out a program and thus would reduce the time to complete a project. It would also reduce the level of experience required to begin using the computer, and thus increase the availability of the facility to a larger number of users. Finally, by helping students and programmers correct errors without resource to an instructor or consultant, DITRAN would increase the utility of the facility for educational functions.
in [ACM] CACM 10(01) (Feb 1967) view details
in [ACM] CACM 10(01) (Feb 1967) view details
in [ACM] CACM 10(01) (Feb 1967) 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 10(01) (Feb 1967) 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
I came to Cornell almost 40 years ago as a freshman engineer in the fall of 1961. A lot of what I remember is tied in with computing. I remember the Engineering College had started a whole new curriculum that year and we were the first class of that curriculum. They had us do an introduction to computing part of the introductory course in "What it?s like to be an Engineer" and they taught us CORC. Conway, Maxwell and Walker had done CORC on the 220, I guess Dave Freeman did it on the 1604. We started out on the 220. I remember going over to Rand Hall and learning how to program. It was really exciting. But what I remember now looking back, is that it was kind of the tip of what I remember best about Cornell and what Cornell did for me, was teach me to want to innovate and do new and exciting things. CORC was incredible at the time, and to me, looking back again, it revolutionized teaching and learning about computing. You didn?t get wrapped up in mundane details. You could keep your eye on getting the logic of the program to work and the program, CORC, was telling me about my syntax errors. To me that was truly an amazing thing. And I look back at it and it?s still amazing. It was a technology thing that had real application.
in Oral Histories - Cornell Computing and Information 2002 view details
The next programming advance at Cornell came in the early 1960's, when Professors Richard Conway and William Maxwell of the Department of Industrial Engineering, and Robert J. Walker of the Department of Mathematics wrote an interpretive compiler called CORC, the Cornell Compiler, similar to the widely used BASIC, which was being developed at Dartmouth. Whereas BASIC had a highly structured, formal syntax, CORC was programmed in English statements and was easy to learn and use. Initially written for the 220, and later for the Control Data1604, it increased student usage greatly. Programs submitted before 5 o'clock would be compiled or run during the night, and results made available to the student the next morning. By 1963, approximately 1,000 students were using the computers for coursework. In 1962, the College of Engineering incorporated computer programming as part of the third semester of calculus, and, in the academic year, 1963-1964, 14 credit courses related to computing were offered on campus. Extract: BAC
Cornell was one of the founders of the original Burroughs User Group, the Cooperating Users' Exchange (CUE), of which Robert Gordon of Stanford was the first president, and I was the second. This group had large representation among Universities and military research facilities and, through the urging of this group, the next breakthrough in software was achieved. Burroughs Corporation, in early 1961 published and distributed the Burroughs Algebraic Compiler, " a representation of ALGOL for the Burroughs 220 Data-Processing System". As had board wiring and machine language programming, assemblers now dwindled in importance. We had been using the assembler CAP (Cornell Assembly Program), written in 1959/60 for the Computing Center by an undergraduate student, David J. Waks. With the availability of the CAP assembler and the BAC compiler, programming the 220 was greatly facilitated.
in Oral Histories - Cornell Computing and Information 2002 view details
Instructional Computing
More about the Use of CORC
Although Lesser provides some interesting information
about the use of the Burroughs 220 and the
Control Data 1604 computer for course work by students,
additional information may provide a better
sense of the practices at the time and the load volume
generated. When the CORC process started, it could
be considered rather archaic?students did not prepare
their own input but wrote their programs on specially
prepared coding sheets that facilitated both the writing
and the transfer to punch cards by professional
keypunch operators. Figure 2 gives a sense of the
situation.
The original caption for this pictorial in a Cornell
Computing Center publication circa 1963 was:
With the CORC simplified computing language,
all Cornell students can make use of
the Computing Center. After a student has
completed his program descriptions, it is
punched on cards by the center staff; run
though the computer; then returned to the
center laboratory for correction and resubmission
by the students when necessary.
[...]
At the time it was the practice to record initial runs,
that is the first run after the program deck was
punched by keypunch staff, and the reruns, which
were subsequent runs after corrections were made by
students and until the program produced the expected
results. One measure of the growth is that initial runs
increased by 2.5 times from 1962?63 to 1965?66.
Reruns showed a four-fold increase over this same
period. These increases give witness to the increasing
use of the computer in the instructional programs at
the university. Extract: CORC, CUPL, PL/C
Introduction of PL/C
One of the primary languages for introductory computing
instruction changed from CUPL to PL/C.
Conway and his various associates, who had developed
CORC in the early 1960s then CUPL in the late
1960s, now followed with PL/C as the language of
choice for this purpose. (CORC was used from 1962 to
1966 on both the Burroughs 220 and the Control Data
1604, while CUPL was used from 1965 to 1969 on
both the Control Data 1604 and IBM 360/65.)
Adopting PL/C was in keeping with the computing
industry trend to adopt the PL/I language for more
applications. IBM commissioned Conway13 and his
associates to develop a student version of PL/I, which
was named PL/C, and provided the initial support that
was also supplemented by support from Seimens. The
development of PL/C was built on the previous experience
noted above as well as new technologies, so
when completed it was the first high-performance
compiler with advanced error-correcting techniques
for a subset of the PL/I language. Once under way, the
project was partially funded by income from sales. In
1970–71 more than 100 copies of PL/C had been distributed,
and 60 sales had been made. Later in the
decade, at its peak, PL/C was used at 250 universities
around the world, according to Conway. Members of
the team that produced the first PL/C release were
Conway, Howard Morgan, R. Wagner, and five graduate
students in Computer Science, the principal one
being Tom Wilcox.
in Oral Histories - Cornell Computing and Information 2002 view details
Resources
- CORC from CLP document
