TXL

It took me a little while to start understanding what TXL can do and how to use it. After success in applying XSLT for typesetting, and a failed attempt at an optimizing C compiler written in Common Lisp because the parser combinator library is bad at handling ANSI C, I rekindled my interest in this programming language.

I have a negative opinion on compiler optimization as I rooted to be an APL programmer. Why would someone even try to program in a inefficient way so compiler can optimize their program? If the programming language does not let you specify the program in the most direct way with the intended efficiency, it is probably a badly designed programming language.

However, although the motivation to me behind using TXL is for program optimization, TXL originated from a lack of compiler features back in the day of early programming language design ages. Not speaking of OOP extension, even the elsif and case statement can be a luxury.

Again, this writing is not about teaching TXL, but a general guide on how to understand the various design decisions made in it and how it is a programming language of its own kind.

A language that doesn't affect the way you think about programming is not worth knowing.

Alan Perlis

TXL is a preprocessor. It parses input using a grammar description and applies a transform program to the parsed result.

The transform language used by TXL is closely related to two programming languages: Refal and XSLT.

Let's talk about XSLT first. It transforms XML documents, and is a pure functional language. An XSLT program is defined by a collection of transforms called templates. They either have targets matched using XPath specifiers in the current context of a node, or have a name to be explicitly referenced by apply template XSLT calls. By default, templates are only applied once unless otherwise explicitly programmed to be iterative.

The basic elements of the transform language of TXL, on the other hand, are rules and functions. Rules are matched in the entire document/program context using unification and are applied iteratively by default, while functions are more like the default XSLT template, matched only once in the current node context. The unification and iterative application closely resembles the evaluation model of Refal, at least in my opinion.

Unlike XSLT, which is optionally typed using XML Schema, TXL is strongly typed against the grammar. A replacement rule needs to be of the same type before and after the replacement. One way to work around that when the result needs to be a different type of node than the original is to construct against an empty node. Another more hacky method is using the ability to override grammar to blend the original and target types together, which is a common technique when TXL is used to transform a program in one programming language to another. This makes TXL less find grained compared to the nanopass framework, where the result of each pass can be a derived but different language.