TRAIL(ID:3910/tra010)

for Tabular Rule-Action Interpreted Language

Block-structured language and programming system for the development of programming support systems and translators for problem-oriented languages on minicomputers.
References:
  • Robert Lechner and William Stallings "A minisystem programming language" view details Abstract: TRAIL is a block-structured language and programming system for the development of programming support systems and translators for problem-oriented languages on minicomputers. The programming system includes an interpreter for an intermediate language (IL) into which various source languages (including TRAIL itself) may be translated. The interpreter size is about 1400 bytes. The choice of an interpreted target language was guided by the objectives of minimum object code size and machine independence of the developed software. Both of these have been achieved, at the expense of a 20:1 slowdown of execution speed relative to directly assembled code. The interpreted object code is at least 50% smaller than assembly code. The source language was designed to match the requirements of language translator software; software design directly models syntax checking, context-free translation, and context-sensitive translation aspects, in ascending order of complexity. Anticipated benefits include greater productivity in design and debug phases, and enhanced communication between programmers via simplified documentation procedures. Extract: Overview
    OVERVIEW

    TRAIL stands for Tabular Rule-Action Interpreted Language. - It is self-compilable from a source to an intermediate language (IL). Programs (called graphs) contain labeled statements called rules. Each rule specifies a binary test, an action call, and two GO TO commands. The test outcome determines whether the action is taken or not.

    The binary test portion of a rule appears as either a simple logical expression or a procedure call made to another graph. Every graph is a Boolean-valued function that, on return, signals success or failure at its assigned task. Graphs may have local variables declared and space is dynamically allocated to these variables by a runtime environment stack frame generator. Recursive calls are allowed.

    Semantic action sequences are variable length freeform programs which contain no conditional tests or GO TO commands. Subordinate action calls may be nested to any depth and called from any rule. To handle context-sensitive semantics for language translation, variable values and pointers may be referenced and passed to subordinate actions or graphs. Action operators apply to a runtime workstack that is not erased on action or graph returns.

    TRAIL effectively separates conditional tests and branching decisions (rules) from straight-line code (action sequences). The logical flow of control is directly displayable on a graph, with one node per rule. [...] A source language translator encodes TRAIL rules and actions into byte strings of IL code, thus producing fully portable machine independent IL object code for all but exceptional requirements. The object code to specify each testand name the implied action and pass/fail node exits can be compressed to fixed length (in our implementation, five bytes). Each action sequence is encoded into a variable-length string of IL operators.

    The separation of TRAIL programs into control and computational components is ideal from the standpoint of firmware implementation and systematic techniques for verifying program correctness.
    Extract: Conclusion
    Conclusion
    TRAIL has been designed to support the experimental development of problem-oriented languages, especially conversationa) languages, on a minicomputer. The facilities required include, of course, translators (which translate problem-oriented languages into the TRAIL intermediate language) and support facilities , such as editors , debuggers and an operating system. Our experience with TRAIL so far includes the writing of a translator (in TRAIL) for TRAIL source to TRAIL intermediate language. Also, some experience has been obtained in writing translators and support systems for other languages.

    Our initial objectives in developing a special-purpose systems programming language have been achieved:

    • Readability: The clean separation of the flow of control from the straight - line code makes a TRAIL program remarkably easy to follow.
    • Writability: By the same token, the separation of control and computation components of the language is an aid to the program writer . Writing a TRAIL program is very much the same thing as writing a flowchart for the program. Furthermore, the debugging of programs is simplified by the high visibility of program branchpoints. An online debugger has been implemented which permits the setting of breakpoints at nodes.
    • Object Code Compression: The speed achieved by interpretive execution has been adequate for our applications. Consequently, we have been able to avoid compiling any TRAIL programs and have achieved the anticipated code compressions of between two and three to one.
    • Portability: All the software written in TRAIL (including the TRAIL translator) is portable to any other machine on which the interpreter is implemented. The interpreter in our facility has been written in assembly code and occupies about 1400 bytes.

          in [ACM] Proceedings of the 1973 annual ACM conference Atlanta, Georgia, United States view details