A man-machine string manipulating language 

Text 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

Related languages
Macro SAP => TRAC   Evolution of
TRAC => MINT   Dialect of
TRAC => ML/I   Influence
TRAC => MS2   Written using
TRAC => SAM76   Influence
TRAC => TINT   Implementation
TRAC => TRAC T64   Renaming
TRAC => TRACD   Extension of
TRAC => TRAK   Implementation of
TRAC => TRIX   Derivation of

  • Mooers, C. N. and Deutsch, L. P., "TRAC, a Text Handling Language" pp229-46 view details Abstract: THE TRAC SYSTEM for Text Reckoning And Compiling was developed as a software package and user language to go with the reactive typewriter. Design goals included the attainment of a concise and efficient input language, a straightforward philosophy and a high order of logical versatility. The external and internal forms of the TRAC language are the same. TRAC can accept, name, store, operate upon in any way, and emit any string of characters that can be produced on a teletypewriter keyboard. Any string can be treated at any time as text, name, or program. This paper describes the design decisions that went into the construction of the TRAC language and system. The acronym TRAC stands for “text reckoning and compiling”1. The TRAC system had its genesis in the need for a general tool for dealing with text. In its later stages, TRAC developed in parallel with the evolution of the reactive typewriter concept2. TRAC is now running in a time-shared environment, and is currently undergoing testing and operational refinement3. In preliminary assessment, TRAC appears to exceed the design targets set for it.
          in [ACM] Proceedings of the 1965 20th National Conference 1965 , Cleveland, Ohio, United States view details
  • Strachey, C., "A General Purpose Macrogenerator" view details
          in The Computer Journal 8(3) October 1965 view details
  • Campbell, D. J. review of Mooers 1966 view details Abstract: A good formal description of the TRAC language is given in this paper. TRAC offers several unique and significant properties that make it especially attractive as a command language. Thus, study of TRAC is a necessity for those engaged in language development. This paper does not give sufficient motivational or tutorial material to demonstrate the remarkable power inherent in TRAC. A second paper by the author, which appears in the 1965 ACM National Conference Proceedings, will be helpful in that area. A study of both papers will prove rewarding.

          in ACM Computing Reviews 7(04) July-August 1966 view details
  • Mooers, Calvin N. "TRAC: A Procedure- Describing Language for the Reactive Typewriter" 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
  • Munson, John H. review of Mooers and Deutsch 1965 view details Abstract: TRAC (for Text Reckoning and Compiling) is a language and a system for the manipulation of text from an on-line terminal. This paper discusses the design goals and decisions involved in specifying TRAC. It is a pleasure to read a prospectus in which design goals are discussed so lucidly and with so little dependence on jargon. In spite of its title, however, the paper lacks a description of the resulting language in sufficient detail to specify it adequately, or to indicate its success in meeting its stated goals. For the complete specification, we await a referenced memo "in revision for publication." The short example of TRAC in the present paper indicates that TRAC does not meet the stated goal of bettering LISP as a convenient keyboard language for the nonexpert. A flurry of parentheses and a certain "mystique" are still in evidence.

          in ACM Computing Reviews 7(02) March-April 1966 view details
  • Clapp, Lewis "Time-Sharing System Scorecard" Computer Research Corporation 1967 view details
          in ACM Computing Reviews 7(02) March-April 1966 view details
  • Dammkoehler, Richard A.; Cook, R. A.; and Rawizza, A. R. "TRAC Implementation of macromodufar functions" St. Louis, Miss,. Computer Research Lab., Washington University 1967. (Technical Memorandum No. 18.) view details
          in ACM Computing Reviews 7(02) March-April 1966 view details
  • Sammet, Jean E., "Roster of Programming Languages 1967" view details
          in Computers & Automation 16(6) June 1967 view details
  • Cole, A.J. "Macro Processors", Cambridge U Press view details
          in Computers & Automation 16(6) June 1967 view details
  • Mooers, C. N., "How Some Fundamental Problems Are Treated in the Design of the TRAC Language" view details Abstract: TRAC is a macrogenerator language operating on character strings with versatile interactive capabilities at run time. Unlike many symbol processing or programming languages, it operates at the literal string level instead of at the name level. It uses an explicit functional notation. and has the ability to interpolate any action or value-producing function at any point in any procedural statement. TRAC treats procedural statements the same as general character strings, with the result that any procedure can act on itself as well as on other procedures, thus giving completely general self-referencing capabilities. The representation of the varieties of "nothing" has been a source of great confusion in many languages, and the manner of treatment of this problem in TRAC is discussed. A brief mention is given of the manner of use of TRAC at other installations, where advantage is taken of its uniform syntax and modular construction to extend its capabilities in other directions of local interest. This is done through the definition of new functions which are uniform in syntax and philosophy with the rest of the language. Extract: Introduction
    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
    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
    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
  • Rockford Research memo "NEW POLICY OF STANDARDIZATION AND TRADEMARK FOR TRAC" 1968 view details Extract: Licence

    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
  • Sammet, Jean E. "Revised Annotated Descriptor Based Bibliography for the Use of Computers for Non-Numerical Mathematics" 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
  • Brown, Peter "A survey of macro processors" pp37-88 view details
          in Halpern, Mark I and Shaw Christopher J (eds) "Annual Review in Automatic Programming" (6) 1969 Pergamon Press, Oxford view details
  • Sammet, Jean E. "Computer Languages - Principles and History" Englewood Cliffs, N.J. Prentice-Hall 1969. pp.448-454. view details
          in Halpern, Mark I and Shaw Christopher J (eds) "Annual Review in Automatic Programming" (6) 1969 Pergamon Press, Oxford view details
  • Stock, Karl F. "A listing of some programming languages and their users" in RZ-Informationen. Graz: Rechenzentrum Graz 1971 270 view details Abstract: 321 Programmiersprachen mit Angabe der Computer-Hersteller, auf deren Anlagen die entsprechenden Sprachen verwendet werden kennen. Register der 74 Computer-Firmen; Reihenfolge der Programmiersprachen nach der Anzahl der Herstellerfirmen, auf deren Anlagen die Sprache implementiert ist; Reihenfolge der Herstellerfirmen nach der Anzahl der verwendeten Programmiersprachen.

    [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
  • Sammet, Jean E., "Roster of Programming Languages 1972" 289 view details
          in Computers & Automation 21(6B), 30 Aug 1972 view details
  • Sammet, Jean E. "Roster of Programming Languages for 1973" p147 view details Extract: Description
    Interactive string manipulation language involving nested functions and macro facilities.
          in ACM Computing Reviews 15(04) April 1974 view details
  • Stock, Marylene and Stock, Karl F. "Bibliography of Programming Languages: Books, User Manuals and Articles from PLANKALKUL to PL/I" Verlag Dokumentation, Pullach/Munchen 1973 625 view details Abstract: PREFACE  AND  INTRODUCTION
    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
  • Sammet, Jean E "Roster of programming languages for 1976-77" pp56-85 view details
          in SIGPLAN Notices 13(11) Nov 1978 view details
  • Layzell, P.Z. "The History of Macro-Processors in Programming Language Extensibility" view details
          in The Computer Journal 28(1) January 1985 view details
  • Introduction to Calvin N. Mooers Papers at the Charles Babbage Institute view details External link: here Extract: Mooers and Sammet on TRAC
    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
    • Implementation in Perl

    • TRAC Foundation
      TRAC was first developed between 1959-1964. It was one of the first programming languages designed for keyboard interaction. This site contains many of the technical documents concerning the original TRAC T64 version of TRAC, as well as information on TRAC's creator, Calvin N. Mooers, a pioneer in information science and early computing.

      external link