TTM (programming language)

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 from GAP^[3] and GPM.^[4]

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

TTM 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.

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]

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.

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.

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.

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.

• 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.

• 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).

• Reference implementation for the TTM programming language on GitHub.