{"id":1213,"date":"2010-11-30T21:47:25","date_gmt":"2010-12-01T02:47:25","guid":{"rendered":"http:\/\/scientopia.org\/blogs\/goodmath\/?p=1213"},"modified":"2016-08-02T14:16:03","modified_gmt":"2016-08-02T18:16:03","slug":"the-glorious-horror-of-teco","status":"publish","type":"post","link":"http:\/\/www.goodmath.org\/blog\/2010\/11\/30\/the-glorious-horror-of-teco\/","title":{"rendered":"The Glorious Horror of TECO"},"content":{"rendered":"

In my oh-so-abundant free time, I’ve been working on my own little text editor. And one of my motivations is TECO: one of the oldest, and one of the very best, ever written. It’s both a text editor and<\/em> a programming language – and, in fact, that’s exactly what made it such a brilliant tool. So much of the drudgery of programming is stuff that really could be done by a program. But we’ve spent so much time learning to be fancy that we’ve lost track of that. Nowadays, you can write an emacs lisp program to do the stuff you used to do in TECO; only it’s awkward enough that you usually don’t.<\/p>\n

The problem, though, with just re-implementing TECO with a modern UI is that it was designed in a different time. When TECO was written, every byte was critical. And so the language, the syntax, the structure, it was completely ridiculous. And, as a result, it became the world’s most useful<\/em> pathological programming language. It’s a glorious, hideous, wonderful, horrific piece of computing history<\/p>\n

TECO is one of the most influential pieces of software ever written. If, by chance, you’ve ever heard of a little editor called “emacs”; well, that was originally a set of editor macros for TECO (EMACS = Editor MACroS). As a language, it’s both wonderful and awful. On the good side, The central concept of the language is wonderful: it’s a powerful language for processing text, which works by basically repeatedly finding text that matches some kind of pattern, taking some kind of action when it finds it, and then selecting the next pattern to look for. That’s a very natural, easy to understand way of writing programs to do text processing. On the bad side, it’s got the most god-awful hideous syntax ever imagined.<\/p>\n

<\/p>\n

History<\/h2>\n

TECO deserves a discussion of its history – it’s history is basically the history of how programmers’ editors developed. This is a very<\/em> short version of it, but it’s good enough for this post.<\/p>\n

In the early days, PDP computers used a paper tape for entering programs. (Mainframes mostly used punched cards; minis like the PDPs used paper tape). The big problem with paper tape is that if there’s an error, you need to either create a whole new tape<\/em> containing the correction, or carefully cut and splice the tape together with new segments to create a new tape (and splicing was very<\/em> error prone).<\/p>\n

This was bad. And so, TECO was born. TECO was the “Tape Editor and COrrector”. It was a turing complete programming language in which you could write programs to make your corrections. So you’d feed the TECO program in to the computer first, and then feed the original tape (with errors) into the machine; the TECO program would do the edits you specified, and then you’d feed the program to the compiler. It needed to be Turing complete, because you were writing a program<\/em> to find the stuff that needed to be changed.<\/p>\n

A language designed to live in the paper-tape world had to have some major constraints. First, paper tape is slow<\/em>. Really<\/em> slow. And punching tape is a miserable process. So you really<\/em> wanted to keep things as short as possible. So the syntax of TECO is, to put it mildly, absolutely mind-boggling. Every<\/em> character is a command. And I don’t mean “every punctuation character”, or “every letter”. Every<\/em> character is a command. Letters, numbers, punctuation, line feeds, control characters… Everything.<\/p>\n

But despite the utterly cryptic nature of it, it was good. It was very<\/em> good. So when people started to use interactive teletypes (at 110 baud), they still<\/em> wanted to use TECO. And so it evolved. But that basic tape-based syntax remained.<\/p>\n

When screen-addressable terminals came along – vt52s and such – suddenly, you could write programs that used cursor control! The idea of a full-screen editor came along. Of course, TECO lovers wanted their full screen editor to be TECO. For Vaxes, one of the very first full screen editors was a version of TECO that displayed a screen full of text, and did commands as you typed them; and for commands that actually needed extra input (like search), it used a mode-line on the bottom of the screen (exactly the way that emacs does now).<\/p>\n

Not too long after that, Richard Stallman and James Gosling wrote emacs – the editor macros for TECO. Originally, it was nothing but editor macros for TECO to make the full screen editor easier to use. But eventually, they rewrote it from scratch, to be Lisp based. And not long after that, TECO faded away, only to be remembered by a bunch of aging geeks. The syntax of TECO killed it; the simple fact is, if you have an alternative to the mind-boggling hideousness that is TECO syntax, you’re willing to put up with a less powerful language that you can actually read<\/em>. So almost everyone would rather write their programs in Emacs lisp than in TECO, even if TECO was<\/em> the better language.<\/p>\n

The shame of TECO’s death is that it was actually a really nice programming language. To this day, I still come across things that I need to do that are better suited to TECO than to any modern day programming language that I know. The problem though, and the reason that it’s disappeared so thoroughly, is that the syntax<\/em> of TECO is so mind-bogglingly awful that no one, not even someone as insane as I am, would try to write code in it when there are other options available.<\/p>\n

A Taste of TECO Programming<\/h3>\n

Before jumping in in and explaining the basics of TECO in some detail, let’s take a quick look at a really simple TECO program. This program is absolutely remarkably<\/em> clear and readable for TECO source. It even uses a trick to allow it to do comments. The things that look like comments are actually “goto” targets.<\/p>\n

\n0uz                      ! clear repeat flag !\n<j 0aua l                ! load 1st char into register A !\n<0aub                    ! load 1st char of next line into B !\nqa-qb\"g xa k -l ga-1uz ' ! if A>B, switch lines and set flag !\nqbua                     ! load B into A !\nl .-z;>                  ! loop back if another line in buffer !\nqz;>                     ! repeat if a switch was made last pass !\n<\/pre>\n
The basic idea of TECO programming is pretty simple: search for something that matches some kind of pattern; perform some kind of edit operation on the location you found; and then choose new search to find the next thing to do.<\/p>\n
The example program above is a rather sophisticated version of that for such a small program. It searches for the beginnings of consecutive lines. For each pair of lines, if they’re not in sorted order, it swaps them, and then searches for the next pair of lines. That’s enclosed in a loop which keeps repeated the scan through the file up until every consecutive pair is in order. In other words, it’s a swap-sort.<\/p>\n
The fundamental (the only?) data structure in TECO is a buffer<\/em>. All TECO programs are based on the idea that you’ve got a buffer full of text, and you want to do something to change it. The way that you access a buffer is through a cursor<\/em>, which is a pointer into the buffer, which represents the position at which any edit operations will be performed. So TECO operations all work by either reading text at the cursor; editing text at the cursor; or moving the cursor. In TECO lingo, the position of the cursor is called dot<\/em>. Dot is always between<\/em> two characters.<\/p>\n
TECO Commands<\/h3>\n
I can’t possibly explain all of TECO in one post, so I’m just going to go through enough to give you the flavor, and to make it possible to walk you through a sample program. If you want, you can go and see the full command list<\/a>, or even read the TECO manual<\/a>.<\/p>\n
TECO commands are generally single characters. But there is some additional structure to allow arguments. There are two types of arguments: numeric arguments, and text arguments. Numeric arguments come before<\/em> the command; text arguments come after<\/em> the command. Numeric values used as arguments can be either literal numbers, commands that return numeric values, “.” (for the index of the buffer pointer), or numeric values joined by arithmetic operators like “+”, “-“, etc.<\/p>\n
So, for example, the C<\/code> command moves the pointer forward one character. If it’s preceded by a numeric argument N<\/em>, it will move forward N<\/em> characters. The J<\/code> command jumps the pointer to a specific location in the buffer: the numeric argument is the offset from the beginning of the buffer to the location where the pointer should be placed.<\/p>\n
String arguments come after<\/em> the command. Each string argument can be delimited in one of two ways. By default, a string argument continues until it sees an Escape character, which marks the end of the string. Alternatively (and easier to read), if the command is prefixed by an “@” character, then the first character<\/em> after the command will be used as a string delimiter, so that the string parameter will continue until the next instance of that character.<\/p>\n
So, for example, the first thing that most TECO programs do is specify what it is that they want to edit – that is, what they want to read into the buffer. The command to do that is “ER”. It needs a string argument to tell it the name of the file to read – so the command to edit a file “foo.txt” is ERfoo.txt<\/code> (followed by pressing escape twice to tell TECO to run the command). Alternatively, you could use one of the other variations for string arguments. For example, you could quote the filename, using @ER'foo.txt'<\/code>. Or you could use quoting in a deliberately silly way: @ER foo.txt <\/code>. (That is, using space as the quote character, giving you nearly invisible quoting.)<\/p>\n
In addition to the standard arguments, you can also modify commands, by placing a “:” in front of them. For most commands, “:” makes them return either a 0 (to indicate that the command failed), or a -1 (to indicate that the command succeeded). For others, the colon does something else<\/em>. The only way to know is to know the command.<\/p>\n
So, now that we know basically what commands and arguments look like, we can start looking at the commands that create the beast that was TECO.<\/p>\n
There are, of course, a bunch of commands for printing out some part of the buffer. Remember, TECO originally comes from the pre-full-screen-editor days, so you needed to be able to ask it to show you what the text looked like after a sequence of edits, to make sure you had it right before you went and saved it. The basic print command is T<\/code>, which prints out the current line. To print a string, you’d use the command ^A (that is, control-A; I said everything is a command!).<\/p>\n
This means that now, we can finally say how to write the good
\n    old classic “Hello, World” program in TECO! It’s very simple:<\/p>\n
\n    @^A'Hello, World!'\n<\/pre>\n
That is, string argument quoted, print, followed by the quoted
\n    string. Perfoctly clear, right?<\/p>\n
There are also, naturally, commands to edit text in various    ways:<\/p>\n
\n
D<\/code><\/dt>\n
 delete the character after the cursor. <\/dd>\n
FD<\/code><\/dt>\n
 Find-and-delete. Takes a string argument, finds the next occurrence of the string, and deletes it.<\/dd>\n
K<\/code><\/dt>\n
 Delete the text from the cursor to the end of the line.<\/dd>\n
HK<\/code><\/dt>\n
 Delete the entire current buffer.<\/dd>\n
I<\/code><\/dt>\n
Insert text. Obviously, this needs a string argument, which is the text that it inserts.<\/dd>\n
<tab><\/code><\/dt>\n
 A second insert command; the only difference is that the tab character is also inserted into the text.<\/dd>\n<\/dl>\n
Next are the commands for moving dot around in the buffer.<\/p>\n
\n
C<\/code><\/dt\n\n\n
 move the pointer forward one character if no argument is supplied; if it gets a numeric argument N<\/code>, it moves forwards N characters. C<\/code> can be preceeded by a “:<\/code>” to return a success value.<\/dd>\n
J<\/code><\/dt>\n
 jumps the pointer to a location specified by its numeric argument. If there is no location specified, it jumps to location 0. J<\/code> can be preceeded by a “:<\/code>” to see if it succeeded. <\/dd>\n
ZJ<\/code><\/dt>\n
 jumps to the position after<\/em> the last character in the file.<\/dd>\n
 L<\/code><\/dt>\n
 pretty much like C<\/code>, except that it moves by lines instead of characters. <\/dd>\n
 R<\/code><\/dt>\n
 moves backwards one character – it’s basically the same as C<\/code> with a negative argument. <\/dd>\n
S<\/code><\/dt>\n
searches for its argument string, and positions the cursor after<\/em> the last character of the search string it found, or at position 0 if the string isn’t found. <\/dd>\n
number,numberFB<\/code><\/dt>\n
 searches for its argument string between the buffer positions specified by the numeric arguments. Search strings can include something almost like regular expressions, but with a much worse syntax. I don’t want to hurt your brain too<\/em> much, so I won’t go into detail.<\/dd>\n<\/dl>\n
TECO has variables; in it’s own inimitable fashion, they’re not called variables; they’re called Q-registers. There are 36 global Q-registers, named “A” through “Z” and “0”-“9”. There are also 36 local<\/em> Q-registers (local to a particular macro<\/em>, aka subroutine), which have a “.”
\ncharacter in front of their name.<\/p>\n
Q-registers are used for two things. First, you can use them as variables: each Q-register stores a string <\/em>and<\/em> an integer. Second, any string stored in a Q-register can be used as a subroutine; in fact, that’s the  only<\/em> way to create a subroutine. The commands to work with Q-registers include:<\/p>\n
\n
nUq<\/code><\/dt>\n
 n<\/code> is a numeric argument; q<\/code> is a register name. This stores the value n<\/code> as the numeric value of the register q<\/code>.<\/dd>\n
m,nUq<\/code><\/dt>\n
 both m<\/code> and n<\/code> are numeric arguments, and q<\/code> is a register name. This stores n<\/code> as the numeric value of register q<\/code>, and then returns m<\/code> as a parameter for the next command.<\/dd>\n
n%q<\/code><\/dt>\n
 add the number n<\/code> to the numeric value stored in register q<\/code>.<\/dd>\n
^Uqstring<\/code><\/dt>\n
 Store the string as the string value of register q<\/code>.<\/dd>\n
:^Uqstring\"<\/code><\/dt>\n
 Append the string parameter to the string value of register q<\/code>.<\/dd>\n
nXq<\/code><\/dt>\n
clear the text value of register q<\/code>, and copy the next n<\/code> lines into its string value.<\/dd>\n
m,nXq<\/code><\/dt>\n
 copy the character range from position m<\/code> to position n<\/code> into register q<\/code>.<\/dd>\n
.,.+nXq<\/code><\/dt>\n
 copy n<\/code> characters following the current buffer pointer into register q<\/code>. <\/dd>\n
*Qq<\/code><\/dt>\n
 use the integer value of register q<\/code> as the parameter to the next command. <\/dd>\n
nQq<\/code><\/dt>\n
 use the ascii value of the n<\/code>th character of register q<\/code> as the parameter to the next command. <\/dd>\n
:Qq<\/code><\/dt>\n
 use the length of the text stored in register q<\/code> as the parameter to the next command.<\/dd>\n
Gq<\/code><\/dt>\n
 copy the text contents of register q<\/code> to the current location of the buffer pointer. <\/dd>\n
Mq<\/code><\/dt>\n
 invoke the contents of register q<\/code> as a subroutine. <\/dd>\n<\/dl>\n
And last, but definitely not least, there’s control flow. First, there are loops. A loop is “n<commands><\/code>“, which executes the text between the left brack and the right bracket “n” times. Within the loop, “;” branches out of the loop if the last search command failed; “n;” exits the loop if the value of “n” is greater than or equal to zero. “:;” exits the loop if the last search succeeded. “F>” jumps to the loop close bracket (think C continue), “F<" jumps back to the beginning of the loop.<\/p>\n
Conditionals are generally written n\"Xthen-command-string|else-command-string'<\/code>. The quotes there are part of the command!) The double-quote character introduces the conditional, and the single-quote marks the end. In this command, the "X" is one of a list of conditional tests, which define how the numeric argument n<\/code>; is to be tested. Some possible values of X<\/code> include:<\/p>\n