> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/nl/diepgaande-artikelen/22-how-does-expandafter-work-the-meaning-of-expansion.md).
# Hoe werkt \expandafter: de betekenis van expansie
[Deel 1](/latex/nl/diepgaande-artikelen/19-how-does-expandafter-work-an-introduction-to-tex-tokens.md) [Deel 2](/latex/nl/diepgaande-artikelen/22-how-does-expandafter-work-the-meaning-of-expansion.md) [Deel 3](/latex/nl/diepgaande-artikelen/21-how-does-expandafter-work-tex-uses-temporary-token-lists.md) [Deel 4](/latex/nl/diepgaande-artikelen/20-how-does-expandafter-work-from-basic-principles-to-exploring-tex-s-source-code.md) [Deel 5](/latex/nl/diepgaande-artikelen/17-how-does-expandafter-work-a-detailed-macro-case-study.md) [Deel 6](/latex/nl/diepgaande-artikelen/18-how-does-expandafter-work-a-detailed-study-of-consecutive-expandafter-commands.md)
## Introductie tot TeX’ concept van “expansie”
Na het besproken te hebben [TeX-tokens en tokenlijsten](https://www.overleaf.com/learn/latex/Articles/\expandafter_TeX_tokens?preview=true), het volgende onderwerp op onze lijst van achtergrondonderwerpen voor `\expandafter` is TeX’ concept van *expansie*: het kernproces van TeX `\expandafter` is ontworpen om mee te werken.
### Over de uitdaging van het uitleggen van expansie...
Voor de meesten van ons kan TeX’ concept van expansie, en de redenen/mechanismen erachter, verwarrend zijn—ze zijn niet gemakkelijk om *volledig* op een eenvoudige, beknopte manier uit te leggen. Veel van TeX’ interne handelingen/processen zijn op vrij complexe manieren met elkaar verweven, wat uitdagingen kan opleveren wanneer men probeert bepaalde aspecten van TeX’ werking te “ontleden”: proberen ze geïsoleerd van het programma als geheel te bespreken. Expansie is zeker een concept dat in die categorie valt, omdat het een *fundamenteel* element van TeX’ gedrag, en diep verankerd in TeX’ interne processen. Dit artikel probeert echter een uitleg van expansie op te bouwen, en biedt een basis waarop lezers verder kunnen bouwen.
Om TeX’ expansiemechanisme uit te leggen, zullen we stap voor stap te werk gaan, waarbij we een reeks verwante/relevante onderwerpen behandelen, en deze samenvoegen om inzicht te ontwikkelen in dit cruciale element van TeX’ gedrag. Later in het artikel, en voor de meer avontuurlijke lezer die van details houdt, kijken we in TeX zelf, en vatten we de belangrijkste broncode samen die het expansieproces aanstuurt.
### Belangrijke punten over TeX-tokens
In de volgende bespreking is het belangrijk te onthouden dat TeX zijn volgende invoerelement uit twee bronnen kan halen:
1. **fysieke tekstbestanden**: door te genereren *nieuwe tokens* door tekens en opdrachten binnen die bestanden te lezen/scannen, of
2. **tokenlijsten**: invoer verkrijgen door te lezen uit een lijst van bestaande, *voorbereide*, tokens die in TeX’ geheugen zijn opgeslagen.
Onthoud ook dat TeX tokens gebruikt als een handige manier om informatie over elk element (teken of opdracht) dat het heeft ingelezen netjes te “verpakken”.
Wanneer TeX genereert *nieuwe tokens* zal het, *op het moment van tokenproductie*, direct toegang hebben tot informatie over het element waarvan het de tokenwaarde berekent. Bijvoorbeeld, bij het genereren van nieuwe opdrachttokens berekent TeX eerst een waarde genaamd `curcs` waarmee TeX informatie kan opzoeken over de opdracht waarvan het op het punt staat de token te produceren.
Als TeX echter uit tokenlijsten leest (reeksen van *opgeslagen tokens*) zou het eerst elke token in die lijst moeten “uitpakken” voordat het kan bepalen wat elke token voorstelt. TeX kan bijvoorbeeld tokens lezen die zijn opgeslagen als onderdeel van een macrodefinitie: die tokens zouden zijn gegenereerd uit tekst die al lang geleden is ingelezen, omgezet in tokens en weggeborgen. Het tokentype (teken of opdracht) bepaalt wat TeX’ “uitpakken” eigenlijk betekent:
* voor *opdrachttokens* (tokenwaarde is > 4095): bereken `curcs` via $$\text{curcs}=\text{token value}-4095$$ en gebruik `curcs` om informatie over de opdracht op te zoeken;
* voor *tekentokens* (tokenwaarde < 4095): splits de tekentoken in de bijbehorende combinatie van (tekencode, categoriecode).
### In het begin...
Om ons onderzoek naar expansie te beginnen, kijken we hoe TeX-engines de set opdrachten die zij kunnen verwerken classificeren, of categoriseren. Neem voorlopig aan dat “expandeerbaar” gewoon een tot dusver onverklaarde “eigenschap” van een TeX-opdracht is.
### Het begrip “expandeerbare” opdrachten
Alle op TeX gebaseerde zetprogramma’s (TeX-“engines”) begrijpen twee hoofd“klassen” van opdrachten:
* opdrachten die in de uitvoerbare engine zelf zijn ingebouwd: de zogenaamde *primitieven*;
* opdrachten die door de gebruiker zijn gedefinieerd: de zogenaamde *macro’s*.
TeX-engines gebruiken ook “expandeerbaar zijn”, een vorm van opdrachts“gedrag”, als mechanisme om alle opdrachten in twee groepen te classificeren:
* expandeerbare opdrachten;
* niet-expandeerbare opdrachten.
We kunnen dus beschouwen dat de set van alle opdrachten (primitieven plus macro’s) kan worden geclassificeerd zoals in de volgende afbeelding te zien is:
Hoewel we nog niet weten wat expansie/expandeerbaar precies betekent, is het mogelijk te zien dat:
* alle macro’s zijn geclassificeerd als expandeerbare opdrachten;
* sommige primitieve (ingebouwde) opdrachten zijn ook geclassificeerd als expandeerbaar (de overgrote meerderheid niet).
**Opmerking over actieve tekens**: Naast primitieven en macro’s is er een derde klasse van “expandeerbare” elementen: actieve tekens—alle tekens waaraan categoriecode 13 is toegewezen worden ook als “expandeerbaar” beschouwd omdat ze als “miniatuurmacro’s” worden verwerkt.
#### Hoe weet TeX of een opdracht “expandeerbaar” is?
Uit onze [bespreking van TeX-tokens](https://www.overleaf.com/learn/latex/Articles/\expandafter_TeX_tokens?preview=true) weten we dat tokens niets meer zijn dan gehele getallen die TeX berekent en gebruikt om informatie over een invoerelement: een teken of een opdracht, te “verpakken”. We merkten ook op dat TeX, gegeven elke token-(gehele)-waarde, indien/nodig het tokeniseringsproces kan omkeren om een token uit te pakken en gegevens te onthullen over de opdracht of het teken dat het vertegenwoordigt.
Met behulp van gegevens die zijn geproduceerd wanneer TeX een nieuw token creëert, of gegevens die zijn gehaald uit een bestaand token—bijv. een token dat is opgeslagen in een macro of andere tokenlijst—kan TeX zijn interne gegevenstabellen raadplegen om gedetailleerde informatie te vinden over de opdracht (of het teken) die door dat token wordt vertegenwoordigd. De volgende afbeelding vat het proces samen van het creëren van een opdrachttoken (“verpakken”) en vervolgens, wanneer TeX informatie nodig heeft, het proces omkeren (“het token uitpakken”) om gegevens te verkrijgen over de opdracht die door een bepaalde tokenwaarde wordt vertegenwoordigd.
### Opdrachtcodes
Een deel van de informatie die TeX over elke opdracht (primitief of macro) opslaat, is iets dat zijn *opdrachtcode*: een gehele waarde die TeX-engines (intern) gebruiken om opdrachten te classificeren—opdrachten met vergelijkbaar gedrag/functionele eigenschappen delen dezelfde opdrachtcode.
**Opmerking**: Voor een individuele, *niet-actieve*, teken, is zijn opdrachtcode de *categoriecode* die eraan werd toegewezen op het moment dat het door TeX werd ingelezen (gescand). Merk ook op dat, behalve voor tekens, opdrachtcodes puur intern aan TeX zijn: ze zijn niet toegankelijk via macro’s of primitieve opdrachten—voor die details moet je de broncode van TeX lezen!
Hier zijn enkele voorbeelden van opdrachtcodes:
* `\hbox`, `\vbox`, `\vtop`, `\vcenter`, `\box` (en andere) worden allemaal geclassificeerd als “boxmaak”opdrachten en delen opdrachtcode 20;
* `\def`, `\edef`, `\gdef`, `\xdef` zijn allemaal “macrodefinitie”opdrachten en delen opdrachtcode 97;
* alle macro’s worden geclassificeerd met een van de opdrachtcodes 111, 112, 113 of 114: de verschillende opdrachtcodes worden bepaald door het gebruik van `\long` of `\outer` bij het definiëren van de macro:
* 111: opdrachtcode voor een niet-long, niet-outer macro (bijv., `\def\foo{...}`)
* 112: opdrachtcode voor een long, niet-outer macro (bijv., `\long\def\foo{...}`)
* 113: opdrachtcode voor een niet-long, outer macro (bijv., `\outer\def\foo{...}`)
* 114: opdrachtcode voor een long, outer macro (bijv., `\long\outer\def\foo{...}`)
TeX gebruikt opdrachtcodes ook om de subset van opdrachten te identificeren die als “expandeerbaar” zijn geclassificeerd. Daarvoor koppelt TeX expandeerbare opdrachten aan opdrachtcodewaarden die de drempelwaarde van 100 overschrijden (de waarde die gebruikt wordt door Knuths originele TeX, e-TeX en pdfTeX). Dienovereenkomstig:
* *niet-expandeerbare* opdrachten (de overgrote meerderheid) hebben een opdrachtcode <= 100
* *expandeerbare* opdrachten hebben een opdrachtcode > 100
Dus als TeX de details van een bepaalde opdracht opzoekt en een opdrachtcode > 100 detecteert, weet TeX onmiddellijk dat deze expandeerbaar is. Alle macro’s en een klein aantal primitieven (ingebouwde opdrachten) krijgen een opdrachtcode die aangeeft dat ze expandeerbaar zijn: maar waarom maakt TeX zich druk om deze “expandeerbare” classificatie? Zoals je misschien vermoedt, betekent het simpelweg dat die opdrachten enigszins “speciaal” zijn; d.w\.z. dat ze kunnen worden onderworpen aan TeX’ proces van *expansie*.
**Opmerking (tekens)**: Tenzij een teken als actief is gedefinieerd (categoriecode 13), zijn alle tekens niet-expandeerbaar. Actieve tekens kunnen worden beschouwd als eenletterige “mini-macro’s”.
## Ja, ja, maar wat is expansie???
We merkten op dat tokenwaarden groter dan 4095 worden gebruikt om opdrachten weer te geven; bijgevolg kan TeX dat token, indien/nodig, “uitpakken” om toegang te krijgen tot informatie over de TeX-opdracht die door dat token wordt vertegenwoordigd. TeX kan de opdrachtcodewaarde van die opdracht opzoeken om te bepalen of deze in de speciale categorie van expandeerbaar zijn valt. Maar wat doet TeX met die informatie en wat betekent “expandeerbaar zijn”, dus expansie, *eigenlijk*?
### Expansie: Een algemene term voor een reeks bewerkingen
Op bepaalde punten tijdens TeX’ verwerking moet het weten of een token een expandeerbare opdracht vertegenwoordigt:
* **Nee**: Als dat opdrachttoken *doet niet* in de expandeerbare categorie valt, geeft TeX het simpelweg “door” aan de volgende verwerkingsfase.
* **Ja**: Als dat opdrachttoken *doet* in de expandeerbare categorie valt, kun je je voorstellen dat TeX actie moet ondernemen die resulteert in het “uitfilteren” van dat specifieke token door een proces uit te voeren dat TeX aanduidt als “dat token expanderen”, of expansie uitvoeren.
In wezen houdt expansie in dat TeX *verwijdert* dat token uit zijn invoer en *vervangt* het door tokens die voortkomen uit het “expansieproces” dat specifiek is voor die opdracht of groep opdrachten die dezelfde opdrachtcode delen.
Het vergt oefening en ervaring om te weten wanneer TeX tokenexpansie wel en niet uitvoert—pagina 215 van The TeXbook somt de situaties op waarin een expandeerbaar token niet wordt geëxpandeerd. De realiteit is dat TeX’ proces van expansie uitvoeren complex en genuanceerd is.
#### Welke opdrachten zijn expandeerbaar?
Als je kijkt naar een lijst van primitieve (ingebouwde) opdrachten die TeX-engines als expandeerbaar classificeren (bijv. pagina’s 212–215 van The TeXbook), wordt duidelijk dat expansie in de praktijk een vrij algemene term is die TeX gebruikt om het gedrag van een enigszins eclectische groep opdrachten te beschrijven. De resultaten van expansie van een bepaalde (expandeerbare) opdracht verschillen inderdaad, en we kunnen dat zien door een set expandeerbare opdrachten op te sommen—gegroepeerd naar hun functionaliteit. De precieze semantiek van individuele opdrachten is hier niet belangrijk; van het meeste belang zijn de algemene gevolgen van hun acties—wat hun expansie eigenlijk *doet of bereikt*.
| **Commando** | **Beschrijving** | **Expansiegedrag** |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| | Een opgeslagen reeks opdracht-/tekentokens | In feite betekent macro-expansie het invoegen van een lijst tokens die TeX moet lezen. Dit houdt in:
- tokenlijsten maken voor eventuele macroargumenten—dat proces omvat het identificeren/absorberen van scheidingsteken-tokens;
- een lijst opgeslagen tokens (de macrodefinitie) ophalen en voorbereiden om de parametertokens die in de eerste stap zijn gemaakt in te voegen (in de macrodefinitie).
Effectief gezien verwijdert het macrotoken uit de invoer verwijderd en vervangt het door de tokens die in de definitie zijn opgenomen.
|
| | De volgorde van expansie wijzigen | Tokenfiltering/-verschuiving |
| | Expansie voorkomen (ja, verrassend genoeg is dit geclassificeerd als een expandeerbare opdracht) | Expansie uitstellen (soort tokenfiltering) |
| \input, \endinput, \scantokens
| Gerelateerd aan het invoeren van een nieuwe tokenbron via bronbestanden—ja, `\scantokens` valt in deze categorie vanwege het gebruik van zogenaamde “pseudo-bestanden” | Fungeren als bron van nieuwe tokens |
| \if, \ifcat, \ifnum, \ifdim, \ifodd, \ifvmode, \ifhmode, \ifmmode, \ifinner, \ifvoid, \ifhbox, \ifvbox, \ifx, \ifeof, \iftrue, \iffalse, \ifcase, \ifdefined, \ifcsname, \iffontchar
| Een conditionele expressie beginnen | Begin met token“filtering”: bepalen welke van de volgende tokens moeten worden verwerkt. |
| | Een conditionele expressie beëindigen | Stop token“filtering”: bepalen welke tokens moeten worden verwerkt |
| | Een opdrachttoken construeren/genereren | Een reeks tokens omzetten in één opdrachttoken |
| \number, \romannumeral, \string, \meaning, \fontname, \jobname, \eTeXrevision
| Iets omzetten in een reeks tokens | Enkele tokens genereren (die een interne grootheid of waarde vertegenwoordigen) |
| \the, \unexpanded, \detokenize
| `\the` heeft verschillende toepassingen, waaronder het invoegen van tokens; `\detokenize` zet een tokenlijst om in een lijst met tekentokens; `\unexpanded` voorkomt expansie van tokens | Enkele tokens invoegen/genereren of expansie regelen |
| \topmark, \firstmark, \botmark, \splitfirstmark, \splitbotmark, \topmarks, \firstmarks, \botmarks, \splitfirstmarks, \splitbotmarks
| Opdrachten voor toegang tot tokenlijsten met gespecialiseerde toepassingen | Toegang krijgen tot een bron van opgeslagen tokens (tokenlijsten) |
Op basis van de bovenstaande lijst, is het mogelijk om enige “algemene gedragingen” uit deze verzameling opdrachten te halen—om ons begrip van expansie verder te verfijnen? Bij benadering komen de resultaten van het expanderen van een opdracht neer op enkele kernactiviteiten:
* tokengeneratie
* tokeninvoeging
* tokenfiltering
* de expansie van het volgende token wijzigen/regelen
### En ten slotte: de betekenis van expansie?
We kunnen beschouwen dat expansie van een opdrachttoken (inclusief actieve tekens) inhoudt dat TeX **verwijdert** dat opdrachttoken uit de invoer verwijdert en **vervangt** dat token vervangt door andere tokens die voortkomen uit zijn expansiegedrag: tokens genereren/invoegen, tokens filteren of de expansie van het volgende token wijzigen/regelen. Zodra een token is geëxpandeerd, zou TeX doorgaan met het lezen/verwerken van eventuele tokens die uit het expansieproces kunnen voortkomen. Precies wanneer of waar TeX expansie uitvoert is een heel andere vraag: vanwege de nuances en complexiteit van TeX’ verwerking kunnen we die in dit artikel niet volledig behandelen, maar we kunnen wel een overzicht geven van TeX’ belangrijkste invoerverwerkingsgedrag.
## Expansie en de structuur van TeX
Waarschijnlijk is de beste manier om te zien hoe/waar TeX onderscheid maakt tussen expandeerbare en niet-expandeerbare opdrachten, door naar de broncode van TeX te kijken.
Intern is TeX een uiterst complex stuk software; bijgevolg is het onpraktisch om een volledige beschrijving te proberen te geven van de vele genuanceerde gedragingen die inherent zijn aan TeX’ werking. Zoals vermeld is precies wanneer of waar TeX daadwerkelijk expansie uitvoert terwijl het tokens leest “enigszins complex”; daarom gaat de volgende bespreking ervan uit dat TeX zich in een toestand bevindt die vereist dat expansie plaatsvindt. Situaties waarin TeX tokens zou lezen/maken maar geen expansie uitvoert, omvatten het maken/opslag van tokens voor de `\def` macrodefinitieopdracht of het opslaan van tokens in een `\toks` register.
Het volgende diagram geeft een vereenvoudigd overzicht van de kernonderdelen van TeX’ structuur die zich bezighouden met invoer en verwerking van tokens: het doel is de manier te benadrukken waarop expandeerbare en niet-expandeerbare tokens worden “gefilterd” tijdens TeX’ invoerverwerking. De C-programmeertaal wordt gebruikt om de verschillende kernfuncties te beschrijven, maar hopelijk moet de basisstructuur duidelijk zijn, zelfs als je niet bekend bent met de C-taal.
### Uitleg van het TeX-structuurdiagram
In hoofdlijnen wordt TeX’ verwerking gestuurd door een functie genaamd `maincontrol()` die Knuth in de broncode van TeX de “chief executive” noemt en als volgt beschrijft:
> “We komen nu bij de `maincontrol` routine, die de hoofdschakelaar bevat die ervoor zorgt dat alle verschillende onderdelen van TeX hun werk doen, in de juiste volgorde… dit is het grote hoogtepunt van het programma… We bevinden ons nu in de spil van het web, het centrale zenuwstelsel dat de meeste andere delen aanraakt en met elkaar verbindt.”
De volgende beschrijving is enigszins vereenvoudigd maar geeft een “sfeer” van de onderliggende structuur van TeX-gebaseerde software: hoe expandeerbare en niet-expandeerbare opdrachten worden geïdentificeerd (“onderschept”) en eruit gefilterd tijdens TeX’ invoerverwerking.
In wezen gebruikt TeX tijdens de vroegste fase van zijn invoerverwerking de opdrachtcodewaarde van de huidige opdracht (token) om expandeerbare opdrachten te detecteren (macro’s, expandeerbare primitieven en actieve tekens); als er een wordt geïdentificeerd, worden dergelijke opdrachten “onderschept” en “voorverwerkt”—door ze te expanderen. Door dit filterings- (expansie-) proces verwijdert TeX expandeerbare opdrachten uit de invoer en vervangt ze door tokens die voortkomen uit hun respectieve expansiegedrag. Zodra het expansieproces voltooid is, leest TeX eventuele tokens die uit die expansie zijn voortgekomen. Alleen niet-expandeerbare items worden doorgestuurd naar de volgende fase van TeX’ verwerking: de “grote schakelaar” waar TeX alle niet-expandeerbare primitieve opdrachten uitvoert en tekens zet.
### maincontrol() begrijpen
De `maincontrol()` functie bevat een grote zogenaamde [switch-instructie](https://en.wikipedia.org/wiki/Switch_statement)—Knuth noemt het de “grote schakelaar”—die TeX gebruikt om alle *niet-expandeerbare* primitieve opdrachten uit te voeren: die met een opdrachtcode <=100.
Om een bepaalde opdracht (of teken) uit te voeren, gebruikt deze “grote schakelaar” een combinatie van TeX’ huidige modus:
* interne/buitenste verticale modus, of
* beperkte/alinea-horizontale modus, of
* inline/weergave-wiskundemodus
*plus* de waarde van de opdrachtcode voor elke primitieve opdracht of teken—de opdrachtcode van een *niet-actieve* teken is zijn *categoriecode* waarde. Ter informatie: alle 6 modi van TeX krijgen een gehele waarde toegewezen die TeX kan gebruiken om zijn huidige modus op te slaan en te herstellen terwijl het schakelt tussen het zetten van verschillende constructies—wiskunde, alinea’s, dozen en zo verder. Hier zijn de gehele waarden die aan TeX’ verschillende modi zijn toegewezen:
| | | |
| -------------------------- | ----------------------------------------- | --------------- |
| **Modus** | **Betekenis** | **Moduswaarde** |
| Buitenste verticale | Tussen alinea’s (pagina’s opbouwen) | 1 |
| Interne verticale | Direct binnen een `\vbox{...}` | -1 |
| Horizontale | Bij het zetten/opbouwen van alinea’s | 102 |
| Beperkte horizontale | Direct binnen een `\hbox{...}` | -102 |
| Weergave-wiskunde | Zetten *weergave* vergelijkingen/formules | 203 |
| In-line (formule) wiskunde | Zetten *inline* vergelijkingen/formules | -203 |
Let op het gebruik van negatieve waarden voor het complement van de verschillende modi, zoals interne versus buitenste verticale modus. Bij het verwerken van opdrachten in `maincontrol()`, gebruikt TeX de absolute waarde van de huidige modus—d.w\.z. negeert het minteken. Dus bijvoorbeeld, als TeX zich in een van zijn horizontale modi bevindt en een teken met categoriecode 11 moet verwerken, zou het de som gebruiken $$102 + 11 = 113$$ binnen zijn “grote schakelaar” om af te takken naar de code die die tekens in beide horizontale modi verwerkt (alinea’s opbouwen of binnen een `\hbox`).
#### Het volgende token ophalen
De `maincontrol()` functie roept de functie `getxtoken()` aan om het volgende invoertoken op te halen; op zijn beurt `getxtoken()` roept de laagste invoerfunctie aan `getnext()`. Nadat `getnext()` zijn werk heeft voltooid en de waarde van belangrijke *globale variabelen*, `getxtoken()` test of het zojuist ingelezen element een macro of een expandeerbare primitieve opdracht vertegenwoordigt.
Enkele opmerkingen over `getnext()` en `getxtoken()`:
* **`getnext()`**: dit is TeX’ kerninvoerfunctie. Het leest en verwerkt tekens die als invoer uit een fysiek bestand komen of leest tokens uit een tokenlijst. Merk op dat `getnext()` niet daadwerkelijk tokenwaarden berekent, maar het stelt wel een aantal belangrijke *globale* variabelen in (bijv. de opdrachtcode en `curcs`) die later in de verwerking worden gebruikt.
* **`getxtoken()`**: “get expanded token” gebruikt `getnext()` om het volgende invoerelement te lezen. Daarna test het de opdrachtcode van het zojuist ingelezen element om te controleren of dat element een expandeerbare opdracht vertegenwoordigt: zo ja, dan wordt het geëxpandeerd of de macro aangeroepen. Voor niet-expandeerbare elementen `getxtoken()` berekent het een tokenwaarde en worden deze details doorgegeven aan de volgende verwerkingsfase: de “grote schakelaar” waar niet-expandeerbare primitieven worden uitgevoerd en tekens worden gezet.
In wezen is het via `getxtoken()` dat alle expandeerbare items worden “weggefilterd” voordat ze worden verwerkt in `maincontrol()`: dit zorgt ervoor dat TeX’ “grote schakelaar” alleen niet-expandeerbare primitieve opdrachten verwerkt.
We benadrukken nogmaals dat het bovenstaande diagram een vereenvoudiging is, omdat andere delen van TeX’ verwerking ook tokens zullen laten expanderen; bijvoorbeeld:
* wanneer TeX zoekt (scant) naar numerieke waarden, zal het expansie triggeren in zijn zoektocht naar gehele getallen (door het aanroepen van `getxtoken()`) ;
* de primitieve opdracht `\romannumeral` zorgt voor expansie—zie het artikel [Expansie met behulp van `\romannumeral`](https://www.texdev.net/2011/07/05/expansion-using-romannumeral/) voor een genuanceerd gebruik van dat feit;
* De `\edef` (“uitgebreide definitie”) macrodefinitieopdracht dwingt volledige expansie af;
* TeX zal tokens op bepaalde punten expanderen bij het verwerken van de preambule van een `\halign` of `\valign` (beide opdrachten zijn gerelateerd aan TeX’ algoritmen voor het zetten van tabellen).
[Deel 1](/latex/nl/diepgaande-artikelen/19-how-does-expandafter-work-an-introduction-to-tex-tokens.md) [Deel 2](/latex/nl/diepgaande-artikelen/22-how-does-expandafter-work-the-meaning-of-expansion.md) [Deel 3](/latex/nl/diepgaande-artikelen/21-how-does-expandafter-work-tex-uses-temporary-token-lists.md) [Deel 4](/latex/nl/diepgaande-artikelen/20-how-does-expandafter-work-from-basic-principles-to-exploring-tex-s-source-code.md) [Deel 5](/latex/nl/diepgaande-artikelen/17-how-does-expandafter-work-a-detailed-macro-case-study.md) [Deel 6](/latex/nl/diepgaande-artikelen/18-how-does-expandafter-work-a-detailed-study-of-consecutive-expandafter-commands.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://overleaf-pro.ayaka.space/latex/nl/diepgaande-artikelen/22-how-does-expandafter-work-the-meaning-of-expansion.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.