Von TeXs Magen aufwärts und 25 Jahre Alois Kabelschachts
\expandafter

1. Verarbeitung von TeXs Tokens durch die Engine mittels Expansion im Gegensatz zu Wertzuweisungen
2. am Beispiel der Implementierung von Programmschleifen durch Makros
3. in möglichst durch reine LaTeX-Nutzer verständlicher Weise, jedenfalls bei mathematischem/informatischem Hintergrund.

– Der Vortrag ist als Abwandlung der Dokumentation des dowith-Pakets gedacht, die schon „25 Jahre Kabelschachts \expandafter“ feierte.

1. Das TeXbook unterscheidet nicht zwischen „Kontrollfolgen“ und „Kontrollfolgentokens“.
2. Dieser Fehler ist bisher in allen Darstellungen von TeX und seinen Spezialanwendungen übernommen worden.
3. Der Vortrag versucht eine bessere Darstellung von TeX.

• Witzigerweise habe ich die Fassung vom 21. Juli 2012 nicht archiviert, sondern die zugrunde liegenden Dateien für den (vorliegenden) „Nachtrag“ direkt weiterbearbeitet.
• Im Vortrag habe ich einiges an der Tafel visualisiert. Vorliegend versuche ich, manches davon in „Folienform“ zu bringen. Die „horizontale Kaskade“ (vgl. Finite state transducer – Computerlinguistik) passte allerdings schon kaum auf die breite(!) Tafel (vgl. nun alphs).

1. „Blick hinter die Kulissen von LaTeX“
   – für „reine“ LaTeX-Nutzer – unter denen manche laut Wikipedia LaTeX von TeX nicht unterscheiden können!?
2. an TeX-Makroprogrammierung interessierte:
   – Vergleich von Tricks bei Konditionalen und Schleifen (die „alte Kunst, Tokens zu sparen“; „Robustheit“/Expandierbarkeit)
3. vielleicht alle: geschicktere Beschreibung der Grundfunktionen von TeX als im TeXbook (dieses „schwer verdaulich“, Peter Wilson, didaktische Lügen …)
4. an theoretischer Informatik Interessierte – wo ich eher Amateur bin (Korrekturen erbeten) Teilprozessoren, Aspekte von Turing-Vollständigkeit

1. Engines und Formate
2. Teilprozessoren und „Privatsprachen“
3. Kommunikation der Teilprozessoren
4. Kontrollfolgen, Kontrollfolgentokens und deren Bedeutung
5. Verarbeitung von Tokens
6. Konditionale, Schleifen

• Typografiekenntnisse
• Kenntnisse der Funktionsweise der TeX-Engine

• Formate bilden durch Makroprogrammierung Abstraktionsschichten – Benutzeroberflächen, Auszeichnungssprache, Programmierschnittstellen – oberhalb der primitiven Engine-Befehle, die die Nutzung lezterer erst praktikabel machen.
• Engines und Formate werden weitgehend unabhängig voneinander entwickelt – die bekannten Formate sind (ursprünglich) älter als die aktuellen Engines, sollen aber – als einmal erlernte Benutzeroberflächen und wie auch ältere Manuskripte (Dokumentdateien) – mit neueren Engines nutzbar bleiben. (Bei ConTeXt und LaTeX3 ist es etwas anders …)

… vgl. TUG resources

Die neueren Engines erweitern Knuths zur Anpassung an allgemeine Neuerungen im Computersatz (und Dokumentenaustausch). Knuths TeX bleibt dabei wesentlicher Bestandteil. Der Vortrag betrifft alle gleichermaßen (bis auf quadrierte Codezeichenzahl bei Unicode).^txt-code

• Plain TeX (Knuth)  ⊂_fast  LaTeX (XeLaTeX, LuaLaTeX?)
• …? ConTeXt
• eplain

• LaTeXs Benutzeroberfläche ist kaum geeignet, die Gestaltungsmöglichkeiten von TeX voll auszuschöpfen
  – dazu muss man die Funktionalität der Engine kennen (das TeXbook oder so).
• LaTeXs „Infrastruktur“ („private“/„interne“ Makros) ist für den Umgang mit der Engine aber sehr hilfreich
  (wird alternativ von eplain oder miniltx angeboten).
• „Zusatzpakete“ von eifrigen „Drittparteien“ (macros/latex/contrib/) schöpfen diese Möglichkeiten immer weiter aus
  und bieten dafür neue „Befehle“ mit „LaTeX-artiger“ Syntax an.

„Tippt man

\foo∗[⟨opt-arg⟩]{⟨mand-arg⟩},

so erhält man …“

• Eine Zeile LaTeX-Code ist (fast) eine Liste (Informatik) oder endliche Folge (Mathematik) von Codezeichen – „String“, „Zeichenkette“.
• Codezeichen betrachte ich als Zahlen von 0 bis 255 (hexadezimal "FF) bei Knuths TeX und pdfTeX bzw. bis "FFFF mit XeTeX^kew117 (und LuaTeX, rate ich). Wenn in LaTeX-Dokumentation „abc“ „als Code“ gesetzt wird (z. B. mit „\texttt{abc}“), bedeutet das mathematisch die Zahlenfolge ("61 ,"62 ,"63).
• Intern arbeitet TeX (die Engine) diese Listen in eine andere Sorte Listen um und bildet noch weitere „Sorten von Listen“ …

It is important to understand the idea of token lists, […] The individual lines of input in your files are seen only by TeX’s „eyes“ and „mouth“; but after that text has been gobbled up, it is sent to TeX’s “stomach” in the form of a token list, and the digestive processes that do the actual typesetting are based entirely on tokens.

– The TeXbook S. 38

(Notation hier, falls jemand fragt:) Etwas genauer enthält Α^∗ zunächst die leere Folge () (Länge 0). Andere Folgen α haben ein erstes Glied b = first(α) und einen „Rest“ β = rest(α) (die Länge von α ist um 1 größer als die von β). Α^∗ ist minimal (zu wählen) mit der Bedingung, dass es zu b in Α und β in Α^∗ ein α mit first(α) = b und rest(α) = β enthält^car – α = b β.

Beispiel: Χ = {0,…,"FF} bzw. {0,…,"FFFF} Menge der Codezeichen  ⇒  Χ^∗ Menge der Strings/Codezeichenketten

Zeichentokens („character tokens“)

• werden zu Glyphen oder haben bestimmte „feste“(?) Steuerungsfunktionen …
• brauchen wir im Vortrag nicht

„Benannte Tokens“ („control sequences“, „control sequence tokens“)

• werden aus „Backslash-Folgen“ (wie „\input“) gebildet
• haben „variable“ Bedeutung …
• jeder Codezeichenkette α aus Χ^∗ entspricht ein benanntes Token ntok(α) mit dem Namen α (soweit TeX Platz hat).

\input MS

(ntok(input), M₁₁, S₁₁)

Es handelt sich eigentlich um ein Plain-TeX-Beispiel, TeXbook S. 7, nicht LaTeX-Konventionen genügende Syntax, würde aber auch mit LaTeX funktionieren.

TeX’s digestive processes always know exactly what a character token signifies, because the category code appears in the token itself; but when the digestive processes encounter a control sequence token, they must look up the current definition of that control sequence in order to figure out what it means.

– The TeXbook S. 39

Das Zitat bebeispielt auch die unterschiedslose Verwendung von „control sequence“ und „control sequence token“ im TeXbook.

TeX’s programming facilities come in two forms—there are TeX’s macros which are expanded in its mouth, and some additional assignment operations like \def which take place in the stomach.

– Alan Jeffrey: “Lists in TeX’s Mouth,” TUGboat Vol. 11 (1990)

… im Gegensatz zu TeX for the Impatient und

Chapter 7 has described the process by which input files are converted to lists of tokens in TeX’s “mouth,” and Chapter 20 explained how expandable tokens are converted to unexpandable ones in TeX’s “gullet” by a process similar to regurgitation.

– The TeXbook S. 267

Dort werden Knuths „Magen“ noch die „Intestines“ (Darm) angefügt, die aus den Seitenkästen das Ausgabeformat erzeugen sollen.^tfti16

Dagegen bezieht sich im TeXbook „stomach“ nach meinem Eindruck auf „den ganzen Rest“ unterhalb der Speiseröhre.

TeX by Topic legt andererseits „eyes“ und „mouth“ als „input processor“ zusammen (aber „two-level“), dessen Darstellung auch inhaltlich nicht fehlerfrei ist.

Überhaupt ist meine Darstellung mit „Prozessoren“ und „Automaten“ wohl durch Eijkhout geprägt.^tbt-fn

Die Menge Τ der Tokens bildet schon wegen des „benannten“ Anteils (ebenso mächtig wie Χ^∗) eine „weniger endliche“ Menge als das „Alphabet“ Χ der Codezeichen. (Hier setzt die buffer size oder jedenfalls das einen festen Gesamtumfang fordernde Design? TeXs eine Grenze.)

Ohnehin enthalten Alphabete etwa der Aussagenlogik, Modallogik und Prädikatenlogik (mathematische Logik, formale Logik) abzählbar unendlich viele Variablen (sind also unendlich, und ich habe unendliche Alphabete nicht hier erfunden).

Merkwürdiger noch: …

Obeying […], TeX’s stomach assembles larger and larger units, starting with characters and ending with pages, and passes the pages to TeX’s intestines.

– TeX for the Impatient S. 47

You can imagine TeX as a kind of organism with “eyes”, “mouth”, “gullet”, “stomach”, and “intestines”. Each part of the organism transforms its input in some way and passes the transformed input to the next stage.

– TeX for the Impatient S. 16

The eyes transform an input file into a sequence of characters.  The mouth transforms the sequence of characters into a sequence of tokens, where each token is either a single character or a control sequence.  The gullet expands the tokens into a sequence of primitive commands, which are also tokens.  The stomach carries out the operations specified by the primitive commands, producing a sequence of pages.  Finally, the intestines transform each page into the form required for the .dvi file and send it there.

• Eingangsalphabet
• Eingangspuffer – enthält stets ein Wort über dem Eingangsalphabet
• Ausgangsalphabet
• „Zustände“ (wie „innerhalb Zeile“, TeXbook S. 46)
• Umwandlungs-/Übergangsregeln (Zustand, Eingangswort) → (Zustand′, Ausgangswort)
• Speicher für „Zwischenergebnisse“ und „Unterbrechungen“ („Keller“-/Stapel-/LIFO- oder aber Ringspeicher-/FIFO-artig)

Ist γ = α β, so heißt α Anfang (und β Ende) von γ.

Im Fall von Codezeichenketten (A = Χ) ist beispielsweise „all“ Anfang von „aller“.^allanf

Und zwar γ = aller, α = all, β = er

Die Konkatenation kann folgendermaßen auf die „konstruktive“ Darstellung (siehe words) zurückgeführt werden (Rekursion nach der Länge des linken Bestandteils): () β = β und (a α′) β = a (α′ β) (vgl. Definition von Addition und Multiplikation mit den Peano-Axiomen).

P macht nun einen Anfang α von π_z aus –

π_z = α β

π_z′ = β  und  ρ_z′ = ρ_z γ

π_z = α β

π_z′ = β  und  ρ_z′ = ρ_z γ

Dann ist γ das Singleton (ntok(α′)), und dem Expansionspuffer wird das Token ntok(α′) angehängt.

You can understand how the processes interact by imagining that each process eagerly gobbles up the output of its predecessor as soon as it becomes available.

– TeX for the Impatient S. 47

2.) Ist der Puffer des aktiven leer, oder fehlen darin Funktionsargumente, so weckt er den nächstäußeren …

3.) Kann ein Prozessor dem nächstinneren ein nicht-leeres „Häppchen“ liefern, so weckt er den und setzt sich selbst wieder zur Ruhe.

4.) Der Dateiprozessor liefert eine ganze Zeile, weiter innen genügt Produktion eines einzelnes Tokens (Nodes?), um sich aus dem Produktionsprozess wieder zu verabschieden.

As far as the stomach is concerned, the input flows in as a stream of tokens, somewhat as if your TeX manuscript had been typed all on one extremely long line.

– The TeXbook S. 38

σ = γ₀ γ_0′ … γ_Y

σ = α_z ρ_z β_z

DP …

• input – TftI S. 46f.: „shifts its gaze“ … „Nachfolgerinhalt“ vs. „nächster Inhalt“

ZP

• catcode – TftI S. 47
• futurelet, aftergroup

EP

• rekursive (TbT) „Selbstaufrufe“

For example, […] the string of characters \input is a control sequence.

– The TeXbook S. 7

(1) A control sequence is considered to be a single object that is no longer composed of a sequence of symbols.

– The TeXbook S. 39

„\input“ ist also zunächst eine Folge von 6 Codezeichen, aber dann, aber dann … ist es ein „einzelnes“, nicht mehr „zusammengesetztes“ Objekt (aus Τ).

– oder:

1. \input ist aus 6 Zeichen zusammengesetzt und
2. \input ist nicht aus 6 Zeichen zusammengesetzt.

1. Das Rätsel der Sphinx
2. Entwicklungsstadien eines (individuellen?) Insekts (Falter, Käfer):
   Ei, Larve (Raupe), Puppe, Imago
3. Klein-Uwe, U. L. blond, vor 5 bzw. 4 Sekunden, grauhaarig, plastiniert
4. Teilchenbahn (Nebelkammer), Planetenbahn
5. Film, Zeichentrickfilm, Buchstaben in Laufschrift (Illusion?)
6. Entwicklungsstadien von „\input“: String, Token, … (… pdfsync etc.)
7. Entwicklungsstadien der Zahl 4: durch die Quadratwurzelfunktion nimmt sie die Gestalt der Zahl 2 an, so dass gilt

   4 < 3

1. Die aus „Kontrollfolgen“ als Elementen von Χ^∗ gebildeten benannten Tokens werden im TeXbook auch „control sequence tokens“ genannt.
2. Es würde mir gut gefallen, wenn das Ergebnis der Konvertierung einer „Kontrollfolge“ „Kontrollfolgentoken“ genannt würde.
3. Im TeXbook werden jedoch (ab S. 39) „control sequence“ und „control sequence token“ gleichbedeutend verwendet (vgl. css-input).

1. Wäre der Backslash wenigstens nicht in „Schreibmaschinenzeichensatz“ („als Code“, „\“) gesetzt, sondern irgendwie als „\“, so hätte man „\input“ gegenüber „\input“ …
2. Deutlicher wäre es, den Backslash bei der Bezeichnung von ntok(input) gar nicht erst ins Spiel zu bringen. Um eine Folge von benannten Tokens darzustellen, wäre „ntok“ allerdings tatsächlich zu umständlich, z. B.

   ntok(let) ntok(next) ntok(iterate)

   aus dem Code

   \let\next\iterate

   → ?-Notation …

1. … zur Erinnerung: um ein benanntes Token zu verarbeiten, muss TeX dessen „aktuelle Definition nachschlagen“ …
2. … präziser fände ich: „dessen aktuelle Bedeutung“ … (allgemeiner)
3. → z. B. ?input kürzer für ntok(input)
4. → allgemein ?χ kürzer für ntok(χ) (χ aus Χ^∗)
5. … verhält sich wie eine Variable –
6. die unterschiedliche Werte annehmen kann –
7. → „Tokenfunktionen“ …

1. †_Lusepackage – damit \usepackage vor \documentclass – liefert eine Fehlermeldung. Statt \usepackage kann aber der „Paketschreiberbefehl“ \RequirePackage verwendet werden.
2. †_Ldocumentclass ändert die Bedeutung von ?usepackage in †_LRequirePackage – das könnte man !usepackage nennen.
3. \begin{document} ruft †_Ldocument auf, was die Bedeutungen von ?usepackage und ?RequirePackage in †_L@notprerr (eine Fehlermeldung) ändert.

1. [ Plastination „schweißt Bestandteile zusammen“ … ]
2. [ „Leerzeichen-Normalisierung“ → Textausgabe = Eingabe (aber \endlinechar=...) ]
3. Vielfach wäre es wohl nur lästig, zwischen Code- und Tokenebene zu unterscheiden.
4. Gegenüber der Funktionsweise der Engine und Plain TeX ist die Code-Token-Wandlung simpel, um Code geht es nur auf wenigen der fast 500 Seiten.
5. Fast alle im TeXbook behandelten Tokens ändern ihre Bedeutung nicht.

1. ?next und ?iterate sind dafür da, durch Änderung ihrer Bedeutungen Konditionale und Schleifen zu steuern. LaTeX übernimmt ?iterate dafür aus Plain TeX.
   [ ähnlich ?do ]
2. Nach †_Pnewif ?ifχ können Konditionale

   ?ifχ τ ^∗else φ ^∗fi

   (τ, φ aus Τ^∗) verwendet werden. ?ifχ bedeutet dabei entweder ^∗iftrue – nach ?χtrue – oder ^∗iffalse – per Voreinstellung oder ?χfalse. Das Konditional wird also durch Änderung der Bedeutung von ?ifχ gesteuert. – Wird in LaTeX zumindest intern verwendet.

Τ_act = { h₁₃ | h aus Χ }

Τ_var = Τ_name ∪ Τ_act

Using its “stomach”, TeX processes the tokens in groups. Each group contains a primitive command followed by its arguments, if any. Most of the commands are of the “typeset this character” variety, so their groups consist of just one token.

– TeX for the Impatient S. 47

2.) Der AP nimmt eine andere Aufteilung von σ in „Funktionsgruppen“ φ_y vor. Gleichung; „Befehl“

• implementiert Benutzeroberfläche/Auszeichnungssprache (Ausführungsfunktionen Menschen nicht zumutbar) – Format!
• Expandierbarkeit, Robustheit, Nebenwirkungsfreiheit …

\def\loop#1\repeat{\def\body{#1}\iterate}
\def\iterate{\body \let\next\iterate
             \else \let\next\relax \fi \next}

\def\iterate{\body \expandafter\iterate\else\fi}

\def\loop#1\repeat{%
    \def\iterate{#1\relax\expandafter\iterate\fi}%
    \iterate \let\iterate\relax}

\def\LaTeXif#1{%
    #1\expandafter\@firstoftwo \else
      \expandafter\@secondoftwo\fi  }
\long\def\@firstoftwo#1#2{#1}
\long\def\@secondoftwo#1#2{#2}

\LaTeXif{⟨test⟩}{⟨ja⟩}{⟨nein⟩}

\TeXif{⟨test⟩}{⟨ja⟩}{⟨nein⟩}

\def\gobblefalse\else\gobbletrue\fi#1#2%
    {\fi#1}
\def\gobbletrue\fi#1#2%
    {\fi#2}
\def\TeXif#1%
    {#1\gobblefalse\else\gobbletrue\fi}

\def\DoWith#1#2{%
    \ifx\StopDoing#2\empty\else
        #1{#2}%
        \expandafter\DoWith\expandafter#1%
    \fi}
\let\StopDoing\DoWith

[ Hier übernimmt Peter Breitenlohner. ]

• Meine, Mathematiker, Informatiker u. ä. müssten die Funktionsweise von TeX doch eigentlich interessant finden – nicht nur ein „Textverarbeitungssystem“! Vielmehr sollte es mit TeX möglich sein, Fachartikel automatisch aus der Messdatenbank zu erzeugen, vgl. TeXbook S. 218 (\primes), Sokal-Affäre, Turing-Test und ELIZA.
• Hoffe zu demonstrieren, dass ein bisschen abstrakte Mathematik (was die meisten von uns im ersten Semester erlebt haben und vielleicht einige immer wieder ihren eigenen Studenten erzählen) auch nützlich ist, um sich irgendwo („unerwartet“) zurechtzufinden.
• Bei Entwicklung von fnlineno.sty und edfnotes.sty …

• Bei Entwicklung von fnlineno.sty und edfnotes.sty wollte ich das Ergebnis rekursiver Makros von Stephan Böttcher (lineno.sty) allgemein beschreiben – erste Vermutungen waren falsch, die nächsten hätte ich mit vollständiger Induktion beweisen wollen … dazu müsste ich TeXs Verarbeitung von Tokens mal formal beschreiben können …

•     blog.sty – erzeugt HTML (siehe blog.pdf)
•  blogdot.sty – für Beamer-„Folien“, siehe blog.pdf
• blogexec.sty – „nicht-funktionale“ Erweiterungen von blog.sty für lokales „minimales Markup“ (vgl. fifinddo-info), siehe blogexec.pdf

Zusammen mit blogexec.sty wurde blog.sty um die „BlogLigs“-Funktionalität erweitert, die wie blogexec.sty die Lesbarkeit des Codes und den Schreibkomfort verbessert und Wiki-artige Auszeichnung implementiert.

[ … Fortsetzung; ^∗csname, damit auch innerhalb; \catcode...=0 … ]

1. χ selbst?
2. \χ vermittels TeXbook-Vermischung?
3. Position in der Hashtabelle oder im Pool

• Registermaschine – drei Grundoperationen; zwei Register genügen
  • Registermaschine (Berechenbarkeitstheorie) – Programm mit Befehlszeiger, unendlich viele Register; „Input-“ und „Output-Wert“!?? „n“!?
  • Registermaschine (Komplexitätstheorie) – Programm (großer Befehlssatz) mit Befehlszähler, Akkumulator, unendlich viele Register