TRAC(ID:276/tra001)A man-machine string manipulating languageText Reckoning And Compiling. 1964 Calvin N. Mooers and Peter Deutsch. An interactive macrogenerator language for string manipulation. Derived ideas from Macro SAP. Versions for PDP-1, PDP-8, PDP-10, PDP-11 Mooers fears of corruption of the language (after the fashion of Fortran dialects) led to his enforcing the language's integrity through trademarks (a tactic that had already failed Yngve with COMIT). This in turn led to its being less used than it otherwise might have been. Also interesting for being the first language worked on by language super-hero Peter Deutsch People: Structures: Related languages
References: in [ACM] Proceedings of the 1965 20th National Conference 1965 , Cleveland, Ohio, United States view details in The Computer Journal 8(3) October 1965 view details in ACM Computing Reviews 7(04) July-August 1966 view details in [ACM] CACM 9(03) March 1966 includes proceedings of the ACM Programming Languages and Pragmatics Conference, San Dimas, California, August 1965 view details in ACM Computing Reviews 7(02) March-April 1966 view details in ACM Computing Reviews 7(02) March-April 1966 view details in ACM Computing Reviews 7(02) March-April 1966 view details in Computers & Automation 16(6) June 1967 view details in Computers & Automation 16(6) June 1967 view details 1. Introduction The subject of symbol manipulation languages is sufficiently new so that we still have difficulty in talking about the languages, their theory, their accomplishments, and their similarities and differences. We are in fact accumulating examples of various languages for study, in the hope that some of them embody new or perhaps unexpected logical features or capabilities, and in the hope that examination of these features may lead to a better understanding of the subject in general. The author believes that the TRAC language, because of its departures from the more conventional paths, and because of its several innovations, is deserving of examination in such a context. The following paper is devoted to the examination and discussion of several interesting features in the TRAC language. The TRAC language [1,2] is a macrogenerator language with an added facile capability for teletypewriter interaction during the running of procedures written in the language. TRAC runs interpretively. It is operational at a number of installations on small and medium size computers, which are usually operating in the time-shared mode. The symbol manipulation systems which have had the greatest influence in inspiring the development of TRAC were Yngve's COMIT, McCarthy's LISP, and, most importantly, the macro assembler Macro SAP of Eastwood and MCIlroy [3]. TRAC should also be compared to the independently developed GPM (general purpose macrogenerator) of Strachey [4] which has a number of remarkable logical similarities and features. The TRAC language can be thought of as taking as a general starting point the ideas of Macro SAP, with the following fundamental modifications: 1) The syntax based on the 80-column Hollerith card is dropped. 2) A uniform syntax and functional notation of the form #(. . . ), where... denotes any string, is introduced. 3) A capability is added to permit input or output to occur at any specified point in any procedure, without the usual restriction permitting input only at the beginning of an operation, and output only at the end of a complete program. 4) Additional appropriate primitive functions are introduced, so that TRAC at present has 35 such functions. 5) A novel distinction between "use" epitomized by #(... ) functions, and "mention" epitomized by ##(.. . ) functions is introduced. 6) Functions to permit use of auxiliary backup storage on drums or discs are introduced. In comparison with LISP, and many other programming languages, the following features are embodied in TRAC: 7) TRAC is designed to operate primarily at the literal string or object level, in distinction to the programming languages that operate primarily at a "symbol", "atom", or "name" level. 8) A simple, very consistent syntax and an explicit simple scanning algorithm is introduced. In this paper, we shall restrict our consideration mainly to the syntactic and philosophic features of the language, rather than to a consideration of the specific primitive functions and to the details of carrying out the flow of control in TRAC procedures Extract: Examples of TRAC Procedures 2. Examples of TRAC Procedures A few examples will give a flavor of the TRAC language, and will explain some of its most important primitive functions. "For"mof'e" detail, the reader is referred to refs. [1,2]. The expression for "print string", as exemplified by # (PS, CAT), will cause the immediate printing out of the string CAT at the connected teletypewriter, irrespective of where it is located in a procedural statement. The "read string" expression # (RS), wherever it may be located, will also cause an action. In this case it causes the acceptance of an input string from the typewriter. For example, the typewritten string THIS IS A DOG' (with the exception of the terminator character') is caused to take the place of the expression # (RS). The terminator character can be changed, such as to *, by use of the "change meta" expression #(CM,*). After execution of such expressions as #(PS,CAT) or #(CM,*), there are no characters left behind in the string being processed. The entire expressions simply disappears. Such expressions are said to have "null value", Le., they produce a value string having no characters. On the other hand, with all expressions like # (RS), which produce a value string with characters, the value string replaces the expression. Any string can be recorded in the store and given a name by the "define string" expression, such as #(DS,Al,PUT THE APPLE ON THE TABLE.) This is a null value expression. The name Al is set up in a table of contents, with pointers to where the text is stored. The string can be brought out from the store by means of the "call" expression, such as #(CL, AI). In this case the expression # (CL, AI) is replaced by the string PUT THE APPLE ON THE TABLE. Dummy or formal variables can be introduced in this string by the "segment string" expression, such as #(SS, AI, TABLE, APPLE), creating a "text macro". Following this, the call takes on the capability of a "macro call". Now the expression #(CL,Al,CHAIR,CAT) produces the string PUT THE CAT ON THE CHAIR. It should be noted that define string expressions can also be used to store procedural statements in TRAC language. Such procedural statements can be converted to procedural macros by the segment string operation, with the result that macro calls to procedures can be made. This causes execution of the procedure with the parameters so inserted. After any series of procedural actions have been completed, and all printout has occurred, the TRAC processor automatically reloads its basic control procedure, called the "idling procedure", # (PS,If(RS)). This procedure, which first tries to complete the #(RS) action, now waits for further input. A simple, very useful procedure in TRAC is the following: #(DS, PROG, ( # (PS, #(CL,#(RS))( ))#(CL, PROG) ))' The parenthesis at t.he end of the first line protects the procedure enclosed from being executed prior to storage. At the end of the second line there is a "carriage return, line feed" which is executed after the string from the call is printed out. The last action of the procedure is to call another copy of itself from the store into the active processing area. The procedure itself occupies lines two and three. The last line holds the necessary matching close parentheses. This statement merely records the procedure. It is put into action by the call1f(CL,PROG)'. Thereupon, if one types in: AI, PLATE, FOOD', out will come: PUT THE FOOD ON THE PLATE and the procedure will re-load itself for further input. The convenience of operation in the PROG mode can be further illus trated by first defining the following recording procedure: #(DS, RECORD, (#(DS, X, Y))) #(SS, RECORD, X, Y)' Thereupon, an input statement like: RECORD, L3, THE LAKE IS BLUE. will store the text THE LAKE IS BLUE. in association with the name L3. It is often desirable to be able to examine a procedure, without causing it to be executed. This is done with a ##(CL,...) expression in the following sense. First note that #(CL, RECORD)' will print out nothi!1g, since it effectively causes execution of the null value expression #(DS, ,). On the other hand, the expression ##(CL, RECORD, AAA, BBB)' will cause the dummy variable positions in the procedure to be filled, and then a copy of the procedure to be printed out without execution, i.e., If(DS, AAA, BBB) will be printed out. With this simple introduction to TRAC procedure, we are now ready to consider some of the logical features of TRAC. Extract: The level of statement in the language 3. The "level" of statement in the language TRAC is unusual among symbol manipulating languages in that its strings are at the "object" or "literal string" level, rather than at the "name" level. This is not an accident. TRAC was designed this way in order to overcome what were believed to be undesirable features of a language operating at the name level. In TRAC, any string of characters is viewed first as an object in its own right. A character string "represents itself". One might say, paraphrasing Gertrude Stein, that a "string is a string is a string". In some instances, as determined by the kinds of argument required by a TRAC function, a string may be considered to be a name for some other string object. Thus in the expression #(CL,AA,BBB)' the string AA is considered (for the moment) to be the name of some string object in the store. However, in TRAC, name strings are not automatically immediately replaced by their value strings (as might appear to be the case with LISP). Instead, a complete TRAC expression such as one containing CL or SS tells first how to interpret the arguments, and then what operation is to be performed on some named value string. If there is a resulting value string, the TRAC expression also tells (through the If -- #If distinction) what is to be done with the result. In other words, in TRAC, a string is not treated as a name without further information. Neither is there any automatic replacement of strings with values. A contrasting philosophy is embodied in LISP, which is a most provocative language to study. In LISP, any string (other. than possibly a "quoted" string) is a "variable", i.e., it is the name either pf an object or data string in the store, or it is the name of some data string yet to be supplied. These two cases of a variable are respectively called "free" and "bound", following the usage of Church (5]. The case of the quoted string in LISP is an exception of sorts. Two views are possible, since the philosophy is not at all clear. They are: 1) The entire expression, such as (QUOTE FISH) might be considered as the name of the object string FISH. 2) The QUOTE operation might also be considered as making the string FISH into an atomic symbol name denoting the object string FISH, with the further provision that the expression as a whole is a redundant name. To continue this interesting comparison, in LISP any atomic symbol (alphabetic string), or any expression such as (CAR(CDR LIST)), or any subexpression such as (CDR LIST) seems to be interpretable in strict fashion only as a name denoting some other object. Evidence of this is the fact that in the S -expressions of LISP, operations such as CAR are strictly onlY to the names of lists, and not to the list themselves [6]. The data objects upon which LISP S-Expressionss operate are insertable only with QUOTE, or as external data strings to which an S-expression is applied. In both cases, the data object must in effect be named before it can be treated. The atomic symbols which are the names of operations, e.g., CDR or LAMBDA are again only the names of objects, in this case the name of a section of programming which performs the desired result. Because LISP is limited to operation at the atomic name level, LISP is easily compiled into an object program on a computer. By the same token, it lacks some of the versatility of TRAC. Although LISP was inspired by the lambda calculus of Church, it is not HO thorough-going as Church's approach. His work may be viewed as an essay in pure symbol manipulation, with little consideration of the semantic question of what objects the symbols denote. For example, Church presents a model based upon a sequence of expressions which is isomorphic to the real number series 1,2,3,. . . . The sequence is: ;>.ab, ab; ;>.ab, a(ab); Xab, a (a(ab»; and so on. In this model, it would be most peculiar indeed to give an explication of what names of objects should be inserted in these dummy variable positions. Since TRAC was designed to be used for performing manipulations upon object strings of literary text, or upon strings describing procedural steps, it was decided that operation primarily at the name level would be burdensome, confusing, and even a little silly. For example, in the simple expression #(DS, SECOND SENTENCE, THE CAT CLIMBED THE TREE)' would become ridiculously complex if names had to be first generated for the second and third argument strings. The versatility of operation at the oU.iect string level is further illustrated in the next section, as we shall now see. Extract: Use of functional syntax 4. Use of "functional" syntax Two operational expressions are used in TRAC. They are represented by #(...) and ## (.. .). Both have the general meaning of "perform the operation indicated by the enclosed list of argument strings". As we have already seen, the difference between the two expressions is concerned with whal is done with any value string produced. In the case of value strings produced by # (. . .), the scanning pointer for the TRAC algorithm is reset to the beginning of the "active" new string just produced. This means that Lhese new strings are again scanned, and any functional expressions found are in turn evaluated, and so on, so long as values are produced by the active functions #(.. .). In the case of the strings produced by the "neutral" functions of the type ## (. . .), the scanning pointer is set to the end of the now value string (Le., the new string is not re-scanned) and thus any funcllonal expressions contained in such a value string are treated just as if they were neutral (non-active) strings of characters. Single paired parenUleses around a string, as in (.. .), act as "quotation marks". Such parenIheses are removed in the scanning, the characters inside are untouched, and the scanning pointer is set to the end of the formerly enclosed string. Only one layer of parenlheses is removed in each scan. Within any TRAC expression, the first argument substring is a two-letter mnemonic expressing the particular action to be taken. The following argument substrings, after they have been scanned, are treated in accordance with the meaning of the mnemonic. Thus the name of the operation to be,performed (given by the mnemonic) is treated on an equal basis with the rest of the substrings in the argument string. It is important to emphasize that the evaluation of a TRAC expression is not undertaken until all the 'internal strings have first been completely parsed and evaluated according to the TRAC scanning algorithm, i.e., until no functions remain to be executed in any active segment of the argument string. In particular, the parsing within an expression does not depend upon the mnemonic found in the first substring of the expression. This is quite different from the action within LISP, for example, where the parsing within an expression apparently must depend upon what is found in the first atomic symbol of an expression. That is, an expression such as «LAMBDA (XY)(PRINT(CONSXY»)(QUOTE A) (QUOTE B) must first be scanned and parsed from left to right, with the parsing within each expression depending locally upon the prior atoms found. Only then can the expression be evaluated, with the evaluation progressing from left to right, from the inside to outside. The scanning and evaluation in TRAC is considerably more flexible in the expressions that it can treat. An expression like # (D# (PS, THE DEFINITION IS NOW OCCURRING)S, A4, JONES IS HERE)' is perfectly good and well-formed. When it is executed, the text THE DEFINITION IS OCCURRING is first printed out at the attached typewriter. There remains for execution the expression # (DS, A4, JONES IS HERE), which causes the recording of the text JONES IS HERE in the store under the name A4. Note especially how the splitting of the function-designating mnemonic DS has no adverse effect either upon the parsing or the execution of the TRAC expression. Another example of the versatility of the TRAC functional expression is #(#(CL,AA)#(CL,BB) where in prior action the name AA was associated with the text EQ, CAT, D and the name BB with the text OG, TRUE, FALSE. When the above expression is executed, the two inner calls are performed, resulting in automatic concatenation, leaving the expression # (EQ, CAT, DOG, TRUE, FALSE) as an active expression still to be executed. The "equality" expression tests for equality between the two literal strings CAT and DOG. Since these strings are not equal, the string value of the complete expression is taken from the fifth argument substring, namely FALSE. Had the strings been equal, the value would have been the fourth argument. Note that the fourth and fifth argument sub strings can be any string or functional expression. Thus TRAC does not have "predicate" functions whose values are restricted to a range of only two pre-set values, such as T and F. The "equals" function in TRAC can therefore be used for transfer of control after a test for string equality by inserting, in the last two substring locations, calls to different sections of procedure. Extract: Treatment of null 5. Treatment of "null" and similar matters At the outset, it would seem that the manner of treating, and of representing, "nothing" would be a simpler matter. Such is not the case. Consider some of the instances of "nothing" which must be dealt with: 1) A specific existent string having no characters 2) An absent or missing string 3) An absent or missing name 4) A specific existent name having no characters 5) A syntactically well-formed expression which expresses no known determinate action, nor expresses a known determinate value. 6) In a text string, the open space between successive words, i.e., the "space" character 7) A numerical quantity whose value is zero 8) In a Hollerith card, a column with no punches . .. and so on. At this time, I believe it is too early to present a comprehensive "theory of nothing". It is, however, of interest to find out how these matters are treated in TRAC. Work with TRAC has convinced me of the logical necessity of making the distinction between a string and its.content. A string is a "form" or "format" which may take or hold cha~act,ers in serial order. If the string holds no chracters, it is a "null string", yet it is still a string. Thus a valid string may have no characters, or l1,lay have many characters. The string exists in either case. String equality between two strings depends upon a character-by-character matching of the two strings. If two strings both have no characters, they specifically satisfy a string equality. Since a string with no characters is a valid string in TRAC, it can be given a name. A null string can also be used as a name with no difficulties except for surprise to workers with experience with other languages. In all respects, except that it has no ordinarily visible print indication, it behaves like any other name. Thus, we can have #(DS, ,CAT)' with the result that #(PS,#(CL,» prints out the string CAT. Note that there was no "space" character between the two commas in the define string function. In the TRAC implementation, a null string is treated uniformly with all other strings, that is, it has a pointer to the beginning of the string a~d another pointer to the end. Such pointers are set up for any string when the string is stored or located by a parsing routine. The only novel feature of the string with no characters is that the two pointers point to the same location, i.e., the beginning of the string is coincident with the end of the string. In TRAC, absent or missing strings are dealt within two ways. If all strings of interest are known to have names; the "name branch" primitive function #(NB, NAME, YES, NO) can be used to find whether the name of the questioned string is in the table of contents. If not, the string is missing from the store. The same test can be used to find whether a name (even if it is a name having no characters) is present. The second method of dealing with absent or missing strings is the technique of making explicit use of the TRAC parsing algorithm with its generation of string bounding markers. Consider the call #(CL, NAME2). This call clearly presents no parameters for filling dummy argument positions. It has only two argument substrings. Additional substrings are simply absent, they are not null. If a TRAC expression cannot for some reason be given any meaningful interpretation, e.g., #(:=, ABC), no action is performed and the value of the expression is taken as the null string. Since concatenation of strings is au tomatic in TRAC, any null string inserted between two non-null strings disappears, which is the effect desired. The evaluation of numerical quantities results in a numerical quantity or value, of which "zero" is an acceptable in~tance. This is expressed by the string cb, and is specifically non-null. Similarly the space character can form a non-null string by itself. It is believed that TRAC has largely avoided the kind of confounding of the several meanings of "nothing" which still plague many of the programming languages which have descended historically from use of the Hollerith card. In the casual use of such cards, no apparent distinction is made between "space", "zero", "no character", and "no string". It is also the author's believe that the treatment of "nothing" in LISP also has a number of logical defects. Unfortunately, the explanations in this area of the LISP language are so confused with implementation that it is difficult to speak accurately about the situation. In the author's understanding of the matter, the symbol NIL is a character string which is an "atom" or a name, but is also" identical to the null list" , i. e., a list having no atoms. To add to the confusion, NIL is also the name of FALSE, or is the circumstance of being false in a logical predicate. It is not at all clear how one would go about dealing specifically with a string of no characters in LISP. Furthermore, the "space" character is taken as a syntactic character (corresponding to the comma in TRAC) with obvious difficulties in dealing with literary text. Extract: Epilogue 7. Epilogue This paper has presented a discussion of some of the logical choices and solutions that went into the development of the features of the TRAC language. The result has been a language that is versatile and modular, and one that is hospitable to a great variety of useful applications. It is of interest to recount that the usual manner of use of TRAC at other installations is to implement the six to ten most important TRAC primitive functions, and then to add four to six specialized primitive functions or user programs of local interest. These new functions are defined so as to be completely consistent with, and modular to, the TRAC language, syntax, and philosophy. Examples of such functions are (a) functions to control a telephone data link and automatic dialling equipment; (b) functions to command a graphic display unit; (c) functions to control mechanical units; (d) functions to control paper tape readers and punches; and (e) functions for digital-to-analog conversion. Several installations have a time-sharing capability built into the basic TRAC translator so that a single small computer can handle a number of typewriters or other peripheral units. Within such a computer, the several TRAC processes are autonomous and have again the property of "modularity" though at a higher level. They are called "TRAC Entities". Such TRAC Entities can communicate with each other, e.g., by "dialling up" from one to the other, and therefore they can create or cause the birth of new TRAC Entities, or they can cause the termination of Entities under their control. Responsibility for various actions and performance of work can be transferred from one Entity to another. Information network operation over telephone or telegraph lines is easily accomplished with a TRAC Entity acting as the ,transformer for the interface languages and procedures used at the remote computer. in Bobrow, D. G. (ed) "Symbol Manipulation Languages and Techniques", Proceedings of the IFIP Working Conference on Symbol Manipulation Languages. North-Holland Publishing Co., Amsterdam, 1968 view details To protect the integrity and compatibility of their family of Trac computer-controlling languages, and to provide for their orderly development, Rockford Research Institute Inc. and Calvin N. Mooers, Rockford President and creator of the languages, have introduced a new doctrine of software protection through autonomous standardization and trademark. The new policy is designed to ensure that Trac does not suffer the traditional fate of other popular computer languages and go through an uncontrolled proliferation into a host of incompatible dialects. This is a serious problem, since the presently-published Trac T-64 language (Mooers, CACM March 1966, pp. 215-219) has already attracted world-wide interest as a powerful, machine-independent string manipulating language for personal on-line reactive typewriter applications. Prompt and effective standardization is imperative so that users everywhere may secure the unique advantages of machine-independent languages -- such as the ability to engage in free and full interchange of interactive procedures written in Trac, and to interchange items drawn from personal data banks organized with Trac. The new doctrine for protection and commercial development of Trac includes the following: (l) Rockford Research has designated itself as the sole source of authentic standards (i.e., technical specifications) for Trac; and (2) Rock-ford Research has adopted the word Trac for its commercial trademark and service mark in connection with its language standards publications, its languages, its software, and its other related goods and services. Trac interpreters and other related software will be leased by Rockford Research and will be maintained to adhere to its standards. Licenses will be offered to on-line computer service bureaus for their use of the Trac trademark in connection with their offering of Trac standard software. Other use of Trac will be licensed appropriately. in Bobrow, D. G. (ed) "Symbol Manipulation Languages and Techniques", Proceedings of the IFIP Working Conference on Symbol Manipulation Languages. North-Holland Publishing Co., Amsterdam, 1968 view details in Bobrow, D. G. (ed) "Symbol Manipulation Languages and Techniques", Proceedings of the IFIP Working Conference on Symbol Manipulation Languages. North-Holland Publishing Co., Amsterdam, 1968 view details in Halpern, Mark I and Shaw Christopher J (eds) "Annual Review in Automatic Programming" (6) 1969 Pergamon Press, Oxford view details in Halpern, Mark I and Shaw Christopher J (eds) "Annual Review in Automatic Programming" (6) 1969 Pergamon Press, Oxford 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 Halpern, Mark I and Shaw Christopher J (eds) "Annual Review in Automatic Programming" (6) 1969 Pergamon Press, Oxford view details in Computers & Automation 21(6B), 30 Aug 1972 view details Interactive string manipulation language involving nested functions and macro facilities. in ACM Computing Reviews 15(04) April 1974 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 Computing Reviews 15(04) April 1974 view details in SIGPLAN Notices 13(11) Nov 1978 view details in The Computer Journal 28(1) January 1985 view details In 1964, Mooers defined TRAC. Jean Sammet, in her Programming Languages: History and Fundamentals, noted that "TRAC has combined concepts of LISP, COMIT, and macro facilities in a very unusual way ... The basic concept in TRAC is that a program consists of strings containing sequences of functions which can be nested indefinitely deeply. Evaluations of these proceed from the innermost level outward, and from left to right within a level, to cause the execution of a program. Furthermore, since the executable statements are treated in the same way as a general character string, a procedure can act upon itself as well as other executable statements, thus giving completely general self-referencing capabilities."(Sammet, 450) Mooers hired L. Peter Deutsch to program TRAC on a PDP-1 at Bolt, Beranek and Newman (BBN) and submitted a descriptive account to Communications of the ACM in 1965. He recalled "the editors, when it came in, evidently were amazed since they had never heard of me. Of course they hadn't heard of me. I hadn't talked about programming languages. I wasn't one of the 'big names.' So I came in with this finished piece of work, and they sent two of their big wheels out to look me over. One of them was Carlos Christensen and the other was Robert Floyd, a big wheel in parsing programming languages. They came to visit me at the office to find out who this guy Mooers was and how come they'd never heard of him. I brought them into the office and took them into the back room and turned on the teletype and we were in remote communications -- with a remote computer at BBN on which TRAC was running and I demonstrated it. So they were all ready to deflate a hoax! Quite different was the fact of the matter. So my paper was published." (Mooers 1966) in The Computer Journal 28(1) January 1985 view details Resources
|