Turing Extender Language (TXL)

TXL has been mentioned briefly before on LTU. There is a recent paper in the LTDA Proceedings 2004 about the motivations of TXL, where the language designers iteratively modified their grammar to suit the intuitive expectations of their users.

Turing uses an asterisk (*) to denote the upper bound of a parameter array (as in array 1..* of int). Users therefore began to write s(3..*) to mean the substring from position 3 to the end of the string, s(1..*-1) to mean the substring from the first position to the second last, s(*-1..*) to mean the substring consisting of the last two characters, and so on. As these forms evolved, the language was modified to adapt to the users’ expectations.

The approach above does sound fruitful, if we want to achieve higher programmer productivity, rapid iterative design of the tools used has a radical chance of making an impact, instead of the path of taking tens of years before a language becomes a productive medium.

Incidentally, TXL allows more than rapid prototyping of the Turing language itself though. Here is an example of how one can override the Pascal grammar.

% Trivial coalesced addition dialect of Pascal
% Based on standard Pascal grammar
include "Pascal.Grm"
% Overrides to allow new statement forms
redefine statement
| [reference] += [expression]
end redefine
% Transform new forms to old
rule main
replace [statement]
V [reference] += E [expression]
V := V + (E)
end rule

The designers of TXL chose Lisp as the model for the underlying semantics, and uses functional programming with full backtracking for both parser and transformer.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

great paper!

I was trying to figure out if allowing 'expression' overloading rather than just operator overloading actually makes sense (I thought it would make it easier to define a 'kernel' language then use that language to extend itself). I didn't even know how to state the problem but this paper (and the AAE paper on the same site) explains it very well!

My initial reaction was that such a system should be part of a programming language itself (as mentioned earlier, describe your own syntax) and that it could be allow easier integration between languages compilers/interpreters (GCC, Parrot, JVM, CLR, etc.).