TTM (programming language)

TTM is a string oriented, general purpose macro processing programming language developed in 1968 by Steven Caine and E. Kent Gordon at the California Institute of Technology.

TTM
Paradigmgeneral-purpose macro processor
Designed bySteven M. Caine and E. Kent Gordon
First appeared1968
Stable release
1.0
LicenseMIT
Major implementations
Unidata TTM
Influenced by
GAP, GPM, TRAC

Description

The following description is taken from the original TTM reference manual[1] and the subsequent batch processing extension.[2]

TTM Is a recursive, interpretive language designed primarily for string manipulation, text editing, macro definition and expansion, and other applications generally classified as systems programming. It is derived, primarily, from GAP[3] and GPM.[4]

Initially, TTM was planned as the macro processing portion of an assembler for the IBM System/360 and, as such, was designed to overcome the restrictions and inconsistencies which existed in the standard assemblers for that system.[5][6]

In addition, it was designed to have all of the power possessed by earlier general macro assemblers but with the unfortunate syntactic and semantic difficulties removed.[7][8][9][10]

During the development of TTM, it became apparent that applications other than assembler macro processing were possible. These include data editing, text manipulation, expression compiling, and macro processing for language processors other than assemblers.

The initial version of TTM was implemented to run in a conversational manner under the Caltech Basic Time Sharing System for the IBM System/360 Model 50.[11] Other versions have been written to run in the batch processing environment of OS/360 and to operate in front of or in conjunction with various language processors.

Syntax and Semantics

The reference implementation assumes that TTM is given a text file containing some combination of ordinary text and TTM function calls (i.e. invocations). The text is scanned character by character. Any ordinary text is passed to the output unchanged (except for escapes). If a TTM function is encountered, it is collected and executed.

The general form of a TTM function call looks like this

#<functionname;arg1;arg2;...;argn>

where the function name and the arguments are arbitrary character strings not containing characters of significance: '#', '<', '>', and ';'. The function is invoked with the specified arguments and the resulting text is inserted into the original text in place of the function call. If the function call was prefixed by a single '#' character, then scanning will resume just before the inserted text from the function call.

This is called active invocation.

If the function call was prefixed by two '#' characters, then scanning resumes just after the inserted text. This is called passive invocation.

During the collection of a function call, additional function calls may be encountered, for example, this.

#<functionname;arg1;#<f2;arg;...>;...;argn>

The nested function call will be invoked when encountered and the result inserted into the text of the outer function call and scanning of the outer function call resumes at the place indicated by the number of '#' characters preceding the nested call.

If a function takes, for example, 2 arguments, any extras are ignored. For user defined functions, if too few arguments are provided, additional one are added with the value of the empty string (""). A function may have a maximum of 62 arguments.

As with other applicative programming languages, a TTM function may be recursive and may be defined as the result of the invocation of a sequence of other function calls.

Functions are either built-in or user defined. A large number of built-in functions exist and are defined in the TTM reference manual[1]

Function definition

User defined functions are created using the following two built-in functions.

  • #<ds;name;text>
  • #<ss;name;text1;text2...;textn>

The first function, ds for "define string", defines a named string in the TTM dictionary. The name is "name" and its value is "text". Invoking this named string will cause its invocation to be replaced by the value (i.e. "text").

The second function, ss for "segment string", scans the text of a previously defined string looking for occurrences of its arguments: text1, text2, ... textn. When an occurrence is found, it is replaced with a segment mark. All occurrences of each argument are replaced by the same segment mark.

When a segmented string is invoked, each argument to the call is substituted for the corresponding segment mark. Consider this example.

[01] #<ds;F;abcxxdefyy>
[02] #<ss;F;xx;yy>
[03] #<F;11;22>

The string F is defined (line 1) and its body "abcxxdefyy" is segmented on the two strings "xx" and "yy" (line2). When invoked (line 3), it will return the value "abc11def22". In effect, we have a user defined function F with two arguments.

Escaping

It is possible to escape one or more characters using either of two conventions.

  1. <...> – escape multiple characters.
  2. @ – escape a single character

If a string is enclosed in <...>, then it is scanned but not interpreted by TTM. In the scanning process, the outer < and > brackets are removed. If there are nested occurrences of <...>, then they are scanned but the < and > are not removed. The brackets must balance: the number of '<' characters must equal the number of '>' characters.

The '@' escape convention causes the interpreter to pass as-is the character after the '@'. The leading '@' is left if it within a <...> escape sequence, otherwise it is removed. One use is to allow unbalanced occurrences of '<' or '>' characters.

Examples

Example 1: Function Definition

The most basic example involves defining a function that is useful for defining additional functions. This "meta" function is called def. It is written as:

#<ds;def;<##<ds;name;<text>>;##<ss;name;subs>>>
#<ss;def;name;subs;text>

We can, for example, use def to define the string XX as 12345 and then segment XX on 34 by writing this.

#<def;XX;34;12345>

The call

#<XX;0000>

will then produce the string "1200005".

The def function operates by invoking ds to define the function name and initial text in the TTM dictionary – XX in our example.

Then the text of the dictionary entry of XX is segmented with respect to any specified arguments: "34" in this case.

When XX is invoked, its argument is substituted for the segment mark.

Example 2: Factorial

The factorial function can be defined (using the above ##<def> function) as follows.

#<def;n!;N;<#<lt;N;2;1;<#<mu;N;#<n!;#<su;N;1>>>>>>>

Notice that the inner computation (#<mu...) is escaped so it will only be evaluated after the #<lt... functions is executed and returns that nested computation as its result.

An example call would look like this.

#<n!;3>

and would return the string 6.

gollark: That role is mostly just filled by crazily power-creeped stuff nowadays.
gollark: My fusion plant thing only had 2 reactors, which easily covered the power needs of everything in existence several times over.
gollark: Also, the highest-end power transmission things I know only go up to 2GRF/t.
gollark: That sounds utterly awful for the server.
gollark: I've generally found that they work nicely at all isolation of things ever if you have power.

See also
  • TRAC programming language

The exact relationship between TTM and TRAC is unknown. The TTM documentation indicates that it was derived from GAP[3] and GPM.[4] In any case, the description of the characteristics of TRAC also apply to TTM. However, by removing the syntactic distinction between built-in and user-defined function, TTM would appear to be a much cleaner language.

Notes
  1. Caine, S. H.; Gordon, E.K. (1968). "TTM: An Experimental Interpretive Language" (PDF). California Institute of Technology, Willis H. Booth Computing Center, Programming Report No. 7.
  2. Caine, S. H.; Gordon, E. K. (May 1969). "TTM: A Macro Language for Batch Processing" (PDF). California Institute of Technology, Willis H. Booth Computing Center, Programming Report No. 8.
  3. Farber, D. J., 635 Assembly System - GAP. Bell Telephone Laboratories Computation Center (1964).
  4. Strachey, C., A General Purpose Macro Generator. Comput J 8, 3(1965), pp. 225-241.
  5. IBM, System/360 Assembler Language, C28-6514-4, (1967).
  6. Caine, S.H. et al., Report of the Systems Objectives and Requirements Committee, SHARE, 1965, pp. 29-40.
  7. Eastwood, D.E. and McIlroy, M.D., Macro Compiler Modification of SAP. Bell Telephone Laboratories omputation Center, 1959.
  8. McClure, R.M., Description of CODAPT Assembler, 1960.
  9. Caine, S.H., Reference Manual for CIT 7090/7040 Experimental Macro Assembly Program (XMAP). California Institute of Technology, Willis H. Booth Computing Center (1964).
  10. McIlroy, M.D., Macro Instruction Extensions of Compiler Languages. CACM 3, No. 4 (1960), 214-220.
  11. Caine, S.H., et al., An Operating Environment for Programming Research. California Institute of Technology, Willis H. Booth Computing Center Programming Report No. 1, 1967.

References
  • Greenwald, I.D. and Kane, M, The Share 709 System: Programming and Modification. JACM 6 No. 2 (1959). pp. 128–133.
  • Greenwald, I.D., Handling Macro Instructions. CACM 2, No. 11 (1959), 21-22.
  • Remington Rand UNIVAC Division, UNIVAC Generalized Programming. Philadelphia, 1957.
  • McIlroy, M.D., Using SAP Macro Instructions to Manipulate Symbolic Expressions. Bell Telephone Laboratories Computation Center (1960).
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.