> 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/sv/fordjupade-artiklar/54-what-is-a-tex-token-list.md). # Vad är en TeX-tokenlista ## Så, vad är egentligen en "TeX-tokenlista"? I en [föregående artikel](/latex/sv/fordjupade-artiklar/53-what-is-a-tex-token.md)—också en del av detta [serie om lågnivå-TeX-nismer](/latex/sv/fordjupade-artiklar/01-a-new-series-of-articles-tex-tokens-and-related-concepts-but-why-and-how.md)—vi utforskade processerna genom vilka TeX skannar din `.tex` fil för att generera nya tokens: vi undersökte den grundläggande naturen hos en TeX-token och hur TeX skapar dem (se [Vad är en "TeX-token"?](/latex/sv/fordjupade-artiklar/53-what-is-a-tex-token.md)). I denna uppföljande artikel tittar vi på *tokenlista*s: vad är de och hur skapar/använder TeX-motorer dem. Det kan vara knepigt att förstå tokenlistor eftersom de lagras djupt i TeX:s interna struktur: dessa detaljer är dolda för användaren—även om det i dag inte alltid stämmer om man gör mer avancerad programmering med LuaTeX. Men för tillfället kan du börja tänka på tokenlistor som TeX:s sätt att lagra en serie heltalsvärden, där varje heltal är en token som härstammar från ett tecken eller kommando som TeX hade läst från din indatafil. Tokenlistor spelar en avgörande roll i TeX:s interna funktion, ofta på något överraskande sätt, till exempel i den interna funktionen hos kommandon som `\uppercase` och `\\lowercase`. En särskilt viktig användning av tokenlistor är att lagra och exekvera makron, ett ämne som vi kommer att undersöka i detalj som en del av en framtida artikel i denna serie. ### TeX får sin indata från filer och tokenlistor TeX-motorer har tre inmatningskällor—två som du kanske känner till: * fysiska textfiler lagrade på disk; * text som en användare skriver in i terminalen (kommandoraden); men det har också ett tredje sätt att läsa/hämta indata: tokenlistor! Tokenlistor är i praktiken en intern datalagringsfunktion som TeX använder som en del av sin verksamhet. Eftersom TeX:s tokenlistor fungerar som ett ”lager” för tidigare skapade tokens, är det logiskt att TeX kan återanvända dem som en annan inmatningskälla. När det blir nödvändigt att ta nästa indata från en viss tokenlista (eller när TeX instrueras att göra det), kommer TeX tillfälligt att sluta läsa indata från en fysisk fil (dvs. skapa *nya tokens*) och växla till att hämta sin indata från *befintliga tokens*: den minnesplats där tokenlistan lagras. Med en tokenlista har uppenbarligen processen för skanning + generering av tokens redan ägt rum, så TeX behöver bara titta på varje token i listan och avgöra vad den ska göra med varje enskild. Som ett snabbt exempel, den lågnivå- (TeX-primitiva) `\toks` kommandot låter dig skapa en lista med tokens som TeX sparar i minnet för senare återanvändning: ```latex \\toks100={Hello} ``` För att hämta dessa tokens (dvs. säga åt TeX att behandla dem som sin nästa inmatningskälla) skulle du använda ett kommando som ```latex \the\toks100 ``` Detta får TeX att växla från att skapa nya tokens från din indatafil till att hämta sin nästa från där dessa tokens (skapade av `\toks`) är lagrade—i ett så kallat *tokenregister* vilket bara är en intern minnesplats som är känd för TeX (här är det register 100). Dessutom kan tokenlistor genereras internt, i farten, av flera TeX-kommandon. Ett exempel är kommandot `\jobname` som genererar en serie teckentokens—en token för varje tecken i namnet på huvudfilen som TeX behandlar. Ett annat exempel är `\string` kommandot; till exempel ```latex \\string\\mymacro ``` genererar en serie teckentokens för varje bokstav i namnet `\\mymacro`—inklusive den inledande `\` tecknet. Vi tar en närmare titt på några ”token-genererande kommandon” i slutet av denna artikel. ## Tokenlista: förklarad med en analogi Om du inte har en programmeringsbakgrund och/eller viss kunskap om datavetenskap kan ”tokenlistor” vara ett ganska luddigt koncept och kanske lite förvirrande. Men om du vill bli skicklig på att skriva TeX/LaTeX-makron kommer en god förståelse för ämnen som TeX-tokens, tokenlistor och kategorikoder (`\\catcode`) att visa sig vara extremt användbar. I detta avsnitt ska vi använda en analogi för att förklara/illustrera kärnidéerna/principerna för en TeX-tokenlista: hur TeX lagrar tokens i minnet. Det är värt att ta sig tid att läsa igenom detta eftersom tokenlistor är en *grundläggande* aspekt av TeX och värd att förstå lite mer i detalj. ### Tokenlistor: en analogi (tankexperiment) Vi ska arbeta oss igenom ett ”tankexperiment” för att ge en grund för att förstå TeX-tokenlistor. Föreställ dig att du hade tillgång till en stor uppsättning behållare, som hundratals burkar—vi kan inte använda termen ”låda” för att beskriva våra tankexperiment-behållare eftersom ”box” förstås har en mycket specifik betydelse i TeX, helt orelaterad till vår diskussion här. Så vi kallar våra behållare för ”burkar”, där varje burk: * har ett unikt identifieringsnummer tryckt på utsidan; * är (internt) uppdelad i två fack. Dessa två fack är utformade enligt följande: * det vänstra facket rymmer det föremål du vill lägga i burken; * det högra facket är avsett att hålla en papperslapp på vilken du kan skriva ett enda nummer: numret som identifierar en annan burk. ![test](/files/759679b9da079e09b3ac6752043cca3e45eea9b2) Anta att du har en samling av, säg, 5 föremål och vill lagra den samlingen i dessa burkar; men tyvärr kan varje burk bara hålla 1 föremål av den typ du vill lagra. För enkelhetens skull, låt oss anta att vi ville lagra 5 färgade cirklar: ![{{{alt}}}](/files/7f3e0108860e0f3008b7f7bf1894acce049dca51) Dessutom, när du går tillbaka för att hämta dessa föremål från ditt lagringssystem (burkarna), ska dessa föremål *måste* hämtas/finnas i en bestämd ordning—den ordning i vilken de lagrades: den sekvensen måste bevaras. Hur kan du åstadkomma detta? Vi kan utnyttja det faktum att varje burk: * har ett unikt identifieringsnummer fäst på utsidan; * har 2 fack—bara 1 av dem kommer vi att använda för att innehålla vårt föremål, det andra innehåller en papperslapp med numret på en annan burk skrivet på den. Vi antar att varje burk är tom—men inget hindrar dig från att öppna en viss burk för att kontrollera om den är tom; om den inte är det, prova nästa tills du hittar en tom burk. Det vi skulle kunna göra är följande. Lägg vårt första föremål (mörkgrön cirkel) i en av våra burkar (t.ex. burk 124) och notera numret på denna första burk—det spelar ingen roll vilket nummer den första burken har, det enda som betyder något är att vi skriver ner det någonstans och sparar det för senare användning. ![{{{alt}}}](/files/c48d3ab1def534907396b9e88fac1b30a642857a) Hitta en andra burk—vilket burknummer som helst (t.ex. burk 432)—och notera dess nummer. Skriv numret på den andra burken (432) på en papperslapp och lägg den lappen *i den första burken* (burk 124). Vi lägger vårt andra föremål (ljusgrön cirkel) i den andra burken. Så vi har för närvarande följande situation: * en skriven lapp—inte lagrad i en burk—som anger att den första burken är nummer 124 (den innehåller vårt första föremål); * i burk 124 har vi lagt till en annan lapp som säger att nästa föremål finns i burk 432. I huvudsak har vi *länkat* våra två första burkar: vi vet var vi ska börja (burk 124) och att en lapp i burk 124 talar om för oss vilken burk som innehåller nästa föremål (burk 432). ![{{{alt}}}](/files/baaf0f5687e2c9ba20eee20ed0749b2f00bb105e) Sedan hittar vi en tredje burk, skriver ner dess nummer (t.ex. burk 543) på en papperslapp och lägger den i *andra* burken (nummer 432). Sedan lägger vi vårt tredje föremål (röd cirkel) i den tredje burken. Nu har vi länkat tre burkar i sekvensen: vår startpunkt, burk 124 (mörkgrön cirkel) → burk 432 (ljusgrön cirkel)→ burk 543 (röd cirkel) →… ![{{{alt}}}](/files/022b0b9ece01dca9342b99c2812e8b0964e7b7e3) Upprepa denna process för de sista två föremålen (ljusblå och mörkblå cirklar) med burk 213 (ljusblå cirkel) och burk 102 (mörkblå cirkel). ![{{{alt}}}](/files/31b708d3acc85b6f98269c3c7017ef09f82dea58) Nu har vi alla 5 burkar länkade till varandra (med hjälp av varje burks numeriska identifierare) och kan hämta alla våra lagrade föremål—i rätt ordning—helt enkelt genom att besöka varje burk i tur och ordning, ta ut vårt föremål och titta på lappen som berättar vilken burk som innehåller vårt nästa föremål. ### Vad händer med det sista föremålet i vår lista (burk 102)? Varför ska vi bry oss om just detta? Hittills har vi lagrat varje föremål i en burk, tillsammans med en lapp som säger vilken burk som innehåller nästa föremål: för det sista föremålet i vår lista, vad ska den lappen säga—det finns ju ingen nästa burk. När vi når det sista föremålet (burken) måste det vara uppenbart att denna burk (som innehåller det sista föremålet) är det sista föremålet i vår lista—vi behöver inte leta efter någon annan burk, eftersom det inte finns någon. Ett sätt att göra det är att placera ett ”speciellt” burknummer i vår sista burk (102). Vi kan använda vilket nummer vi vill förutsatt att vi väljer ett unikt nummer som inte är numret på en faktisk burk—till exempel ”burk -1”, ”burk 0”: det spelar ingen roll så länge vi vet att ”burk -1” eller ”burk 0” osv. omedelbart talar om för oss att sluta leta: vi behöver inte leta efter fler burkar eftersom detta är den sista och det därför inte finns fler föremål att hämta. ### Från ”föremål” och ”burkar” till tokens och TeX Nu behöver vi gå från vår analogi till en beskrivning som ligger närmare TeX:s verklighet. Först och främst, i stället för att lagra olika färgade cirklar i våra imaginära burkar borde det vara tydligt att vi kan tänka på dessa burkar som att de lagrar TeX-tokens: enkla heltal. Det är den enklare delen av att föra över vår analogi till mjukvarans värld (TeX). Men vad skulle kunna vara den mjukvarumässiga motsvarigheten till våra fysiska numrerade burkar med ”fack”? Vi vill inte ge oss för långt in i programmeringsbegrepp, men du kan tänka på våra ”burkar” som ett antal byte datorminne som har ”paketerats” till en bekväm lagringsenhet. Vår analogis användning av en numerisk identifierare för varje burk kan betraktas som platsen i datorminnet där varje liten minnespaket finns. Inom TeX själv kallas dessa små lagringspaket för ”minnesord”—en term som speglar den tid/era då TeX skapades (1970-talet). Dessa ”minnesord” är den grundläggande byggstenen som används inom TeX, men vi behöver inte utforska dem mer i detalj här—den som vill ha mer detaljer kan hänvisa till en artikel om [författarens personliga blogg](http://www.readytext.co.uk/?p=3537). I dataprogrammeringstermer kallas det vi har diskuterat för en [*länkad lista*](https://en.wikipedia.org/wiki/Linked_list): en TeX-tokenlista är en länkad lista byggd av TeX:s lagringsbehållare som kallas *minnesord* där varje minnesord kan användas för att lagra: * a *värde*: tokenens värde (ett heltal); * a *länk*: minnesplatsen för nästa minnesord som innehåller nästa token i vår lista. ## Var använder TeX tokenlistor? Överallt! Detta stämmer eftersom en TeX/LaTeX-makrodefinition (t.ex. ett LaTeX-kommando) lagras som en (något specialiserad) form av tokenlista—specialiserad i den meningen att den innehåller tokens som du inte ser i ”standard” tokenlistor (relaterade till att matcha makroparametrar osv.). Oroa dig inte för detta eftersom vi kommer att ta upp de detaljerna i en framtida artikel. ### Ett exempel på ett makro Ett makro kan tänkas bestå av tre delar: ``` \\def\\{} ``` Observera att i stället för `\def` kunde du ha använt `\edef`, `\gdef` eller `\xdef`. **Anmärkning för LaTeX-användare**: Här definierar vi makron med råa, lågnivå-TeX-kommandon (kallade *primitiver*). LaTeX-användare är mer bekanta med att skapa makron via LaTeX:s `\\newcommand` (som i sig självt är ett makro). När du ber TeX att skapa (definiera) ett makro kommer det att skapa en token som representerar `` och en *tokenlista* som representerar den sammanslagna `` och ``. TeX kommer noggrant att lagra allt så att tokenen som representerar `` är länkad till tokenlistan som representerar dess definition (`` och ``). Till exempel, om vi definierar `\\mymacro` så här: ```latex \\def\\mymacro abc #1 defz{I typed "#1"!} ``` Vi kan se att dess beståndsdelar är: * `` = `mymacro` * `` = `abc #1 defz` * `` = `I typed "#1"!` Till exempel skulle du kunna anropa `\\mymacro` så här: ```latex \\mymacro abc THIS TEXT defz ``` vilket resulterar i `I typed "THIS TEXT"!` att sättas om— `abc` och `defz` är *inte* sätts om. `abc` och `defz` är sekvenser av teckentokens som används för att *avgränsa* makroparametern `#1` och absorberas och kastas bort när ditt makroanrop har behandlats framgångsrikt av TeX. När du definierade `\\mymacro`, fungerar tokenmönstret i den lagrade som en ”mall” som TeX kan använda för att räkna ut: * vilka tokens i din indata som är avgränsartokens; * vilka tokens i din indata som faktiskt utgör parametern/parametrarna i ditt makro (här, det du använder för `#1` i ditt anrop av `\\mymacro`). Du måste anropa `\\mymacro` med en `` som innehåller avgränsare som är identiska med dem som användes för att definiera det—detta inkluderar att använda teckenavgränsare med identiska kategorikoder. Om avgränsarna i `` som används för att anropa `\\mymacro` är annorlunda än dem som användes för att definiera det (den ”mall” som lagras i minnet), kan TeX bli ganska förvirrat—när det försöker behandla `\\mymacro` skulle det inte kunna matcha den ”mall” som det har sparat i sitt minne. När TeX ser att du anropar ett makro kommer det att skanna din indatatext för att skapa nya tokens och försöka, token för token, matcha dem med tokenlistan `` mallen som lagras som en del av ditt makros definition. Om avgränsarna som används i din indatatext resulterar i en serie tokens som inte matchar dem som lagrats i ”mallen”, kommer TeX vanligtvis att ge ett fel. TeX är mycket noggrant—kom ihåg att teckentokens är en kombination av teckenkod och kategorikod: om du ändrar kategorikoden för ett tecken får du ett annat tokenvärde som härrör från det tecknet. Anta att vi ändrade kategorikoden för `z` till, säg, 12—normalt är den 11—och försöker anropa vårt makro så här: ```latex \\catcode`z=12 \\mymacro abc THIS TEXT defz more text here... ``` Den här gången kommer det inte att fungera eftersom kategorikoden för `z` har ändrats. Du kommer att se ett fel som detta: ```latex Rymt argument? THIS TEXT defz ! Stycket slutade innan \\mymacro var färdigt. \par l.22 ``` När TeX läser och skannar `z` i `defz` kan det inte känna igen det som att det utgör slutet på `\\mymacro`’s `` som används i din indatafil. Fram till att det såg detta felaktiga `z` hade TeX korrekt matchat de första 3 tecknen `def` men det `z` (med kategorikod 12) ställer till det för TeX:s skanning. Om vi antar `z` hade kategorikoden 11 när vi *definierade* `\\mymacro`: det skulle resultera i att ett tokenvärde på 256×11 + 122 = 2938 lagrades som en del av `\\mymacro`s definition (dvs. lagrades som en del av ”mallen”). Men med kategorikod 12, `z` kommer nu att skapa ett tokenvärde på 256×12 + 122 = 3194. Eftersom tokenvärdet (för `z`) som läses in från din indata (värde 3194) inte matchar `z`-tokenen som finns i den lagrade `` tokenlistemallen (värde 2938), kommer TeX att fortsätta skanna din indata. TeX kommer att fortsätta skanna texten som följer efter ditt makro (*mer text här* ...) för att leta efter ytterligare tokens—i ett försök att matcha den lagrade mallen med de tokens den hittar i din indata. Det kommer troligen inte att hitta det korrekta tokenmönstret och fel kommer att uppstå när TeX ”överskjuter” din indata och felaktigt läser extra text för att skapa ytterligare tokens—de extra tokens borde inte ha lästs vid denna punkt och kommer nästan säkert att generera ett fel. Vi går in på detta mer i detalj i en framtida artikel. ## Andra användningar av tokenlistor Andra kommandon som används för att skapa/lagra tokenlistor inkluderar: ```latex \\toks={...} \\everypar={...} \\everymath={...} \\everydisplay={...} \\everyhbox={...} \\everyvbox={...} \\output={...} \\everyjob={...} \\everycr={...} \\errhelp={...} ``` Var och en av dessa kommandon skapar en tokenlista från tecknen och kommandona inom klamrarna ’{...}’ och den tokenlistan är avsedd att återanvändas under vissa omständigheter. Till exempel, `\\everypar={...}` skapar och lagrar en uppsättning tokens (en tokenlista) som TeX injicerar i indata precis innan det börjar ett nytt stycke. ## Dolda användningar av tokenlistor: exempel I detta sista avsnitt ska vi titta på några praktiska exempel på tokenlistor som används på sätt som du kanske inte förväntar dig. ### Exempel 1: \\\uppercase{...} och \\\lowercase{....}—tillfälliga tokenlistor Förutom explicita kommandon för att generera tokenlistor finns det omständigheter när TeX genererar en dold och tillfällig intern tokenlista för att utföra särskild bearbetning. Kom ihåg att när TeX läser/bearbetar dina indatatecken/kommandon omvandlas de till tokens: den grundläggande byggstenen som TeX-motorer arbetar med. Ett bra exempel är kommandona `\uppercase{...}` eller `\\lowercase{...}` eftersom deras funktion vid första anblick kan vara ganska förvirrande. När du väl förstår vad de gör—djupare inne i TeX och osynligt för användaren—blir deras funktion mycket lättare att förstå. Anta att du har en enkel serie bokstäver som du vill göra versaler—t.ex. abcde och omvandla det till ABCDE. Tja, med TeX:s `\uppercase` kommandot: ```latex \\uppercase{abcde} ``` kommer TeX att mata ut `ABCDE`. Låt oss nu anta att vi vill spara vår enkla bokstavsserie för senare användning—dvs. vi vill inte skriva ut dem direkt, så vi använder TeX:s enda *interna* mekanism—inte en extern (fil-)mekanism—för att spara data: använd en tokenlista. Vi kan göra det antingen genom att skapa ett makro eller genom att använda ett explicit tokenlistekommando: ```latex \\toks100={abcde} \\def\\mychars{abcde} ``` Sedan kanske du vid något tillfälle bestämmer dig för att du vill återanvända din bokstavsserie men den här gången i versaler; så du försöker ```latex \\uppercase{\\the\\toks100} ``` och ```latex \\uppercase{\\mychars} ``` Men tyvärr fungerar inget av dessa. Varför är det så? ### Hemliga tokenlistor! För att förstå hur kommandona `\uppercase{...}` `\\lowercase{...}` faktiskt fungerar behövde jag titta in i TeX:s inre mekanismer, så följande förklaring bygger på det. När TeX upptäcker antingen `\\uppercase{}` eller `\\lowercase{}` i din indata är det första TeX gör att skapa en (tillfällig) intern tokenlista från `` som är innesluten mellan ’{’ och ’}’ som följer efter `\uppercase{...}` eller `\\lowercase{...}` kommandona—den tillfälliga tokenlistan är intern för TeX. En avgörande punkt, och central för att förstå hur `\\uppercase{}` och `\\lowercase{}` faktiskt fungerar, är att alla kommandon eller makron som finns i `` är inte *expanderats*: allt TeX gör är att generera tokens från tecken och kommandon som placerats mellan `{...}`. Under körningen av `\\uppercase{}` eller `\\lowercase{}` körs ingenting mellan klamrarna: det omvandlas helt enkelt till tokens. Efter `` inuti `{...}` har omvandlats till en (tillfällig) tokenlista, går TeX sedan igenom varje token i den listan på nytt och testar om den är en *tecknet* token eller en *kommandot* token (med hjälp av tokenens numeriska värde). Om TeX upptäcker en teckentoken ändrar det den tokenen för att justera tecknets skiftläge (beroende på om `\uppercase` eller `\\lowercase` bearbetas). TeX ignorerar helt enkelt alla kommandotokens och ”tittar inte in” i några kommandotokens för att se vad de representerar eller innehåller (t.ex. ett makro som innehåller tecken)—de hoppas helt enkelt över: endast teckentokens påverkas faktiskt av skiftlägesändrande operationer. Så, till exempel, om vi använder ett TeX-kommando som `\\uppercase{abcde}` kommer TeX att skapa en tokenlista från `abcde` som endast innehåller teckentokens: de justeras alla för att skapa en serie modifierade tokens som representerar A, B, C, D och E. Dessa modifierade tokens matas tillbaka till TeX:s inmatningsprocessor vilket resulterar i `ABCDE` att sättas om. Men om vi har lagrat våra tecken *i ett makro*—till exempel `\\def\\mychars{abcde}`—och försöker omvandla dem till versaler så här: ```latex \\uppercase{\\mychars} ``` så kommer det att misslyckas och abcde kommer att sättas om—inte ABCDE som du kanske förväntar dig. Om vi sedan försöker lagra våra tecken i en tokenlista som `\\toks0={abcde}` och gör `\\uppercase{\\the\\toks0}` så kommer återigen `\uppercase` att misslyckas eftersom tokenlistan helt kommer att bestå av tokens som inte påverkas av `\uppercase`. Om vi tar vårt makro som exempel, `\\mychars`, när TeX har upptäckt `\uppercase` i indata, slår TeX upp betydelsen av `\uppercase` och utför det, vilket skapar en tillfällig tokenlista från `{\\mychars}`. Den tillfälliga tokenlistan innehåller uppenbarligen bara en token som inte är en teckentoken utan en som representerar vårt makrokommando `\\mychars`: därför, för att utföra `\uppercase`, ignoreras den tokenen—`\\mychars` representerar inte en teckentoken. Men, som nämnt ovan, när `\uppercase` har gjort sitt arbete, matas den tillfälliga tokenlistan (skapad genom att `\uppercase`) tillbaka in i TeX:s fullständiga inmatningsbearbetnings- (skannings-)mekanism. När TeX läser den tokenlistan igen upptäcker det en token som representerar vårt `\\mychars` makro som TeX exekverar (expanderar) och genererar en serie tecken för att sätta om abcde—fortfarande i gemener eftersom de var ”inbakade” i ett makro och därmed osynliga för `\uppercase`. När TeX har granskat den tillfälliga tokenlistan som skapats för `\uppercase{...}` eller `\\lowercase{...}`, och bearbetat eventuella teckentokens, växlar det sedan till att använda den tillfälliga tokenlistan som sin inmatningskälla: sätta om tecken (bearbetade teckentokens) och exekvera kommandon och makron. ### Hur kan detta åtgärdas? Eftersom `\uppercase{...}` eller `\\lowercase{...}` kommer bara att verka på teckentokens, behöver vi ett sätt att ”tvinga uppackning” av tecken som finns i vårt makro `\\mychars` (eller som finns i en `\toks` register) innan `\uppercase{...}` eller `\\lowercase{...}` verkar på det. Med ”uppackning” menar vi egentligen TeX:s process att *expansion*: * ersätta ett TeX/LaTeX-kommando med den *sekvens* av tokens *som det kommandot* (*t.ex. ett makro*) *består av,* eller * och producera den sekvens av tokens som ett kommando är avsett att *generera*. Ett exempel på ett kommando som genererar tokens är `\jobname`, vilket producerar en sekvens av teckentokens som representerar namnet på huvud-TeX-filen som behandlas. #### Lågnivåmagi: scantoks(..., ...) Här gräver vi verkligen i några mörkare hörn av TeX:s inre mekanismer så du kan ignorera detta avsnitt om du inte gillar detaljerna… När TeX upptäcker `\uppercase` eller `\\lowercase` i inmatningsströmmen, exekverar det en intern funktion som heter `scantoks(..., ...)` vars uppgift är att generera tokenlistan med hjälp av innehållet mellan den öppnande ’{’ och den avslutande ’}’—som nämnts granskas den tokenlistan därefter för att upptäcka (och sedan justera) eventuella teckentokens för att ändra tecknens skiftläge enligt behov. Observera noga att vi syftar på `scantoks(..., ...)` som den interna funktionen inbyggd i källkoden för TeX-motorer—här avses det inte som namnet på en kontrollsekvens. Som en del av sitt arbete, `scantoks(..., ...)` kan det instrueras om huruvida det ska expandera eller inte expandera tokenlistan som det konstruerar och för `\uppercase` och (`\\lowercase`) expanderar det inte tokens: det skapar dem bara och lägger dem i en tokenlista. En av de första sakerna som `scantoks(..., ...)` måste göra är att kontrollera en öppnande ’{’ (eller något tecken med `\\catcode` 1) eftersom det måste säkerställa att användaren inte har gjort ett syntaxfel och glömt den öppnande ’{’ (eller något tecken med kategorikod 1)—eftersom ett tecken med kategorikod 1 krävs för att avgränsa början på en lista med objekt som ska tokeniseras. Och här är tricket: uppgiften att leta efter en öppnande ’{’ utlöser `scantoks(..., ...)` att köra TeX:s expansionsprocess, vilket betyder att följande exempel kommer att fungera: ```latex \\let\\ob={ \\uppercase\\ob abcde} \\def\\obb{\\ob} \\uppercase\\obb xyz} ``` Om vi tar exemplet med `\\obb`, ett makro, känns det igen som en *expanderbart kommando* och expanderas därför av TeX (via `scantoks(..., ...)` funktionen) i dess sökande efter en öppnande klammer (vilket tecken som helst med kategorikod 1). Det betyder att vi kan använda ”`\expandafter` tricket” för att nå vårt mål att ”packa upp” våra tecken ur vårt makros begränsningar—dvs. expandera det. Observera att `\expandafter` faller också under kategorin att vara en *expanderbart kommando*, så TeX utför det här och låter det göra sitt arbete som en del av jakten på en öppnande ’{’ (eller något tecken med kategorikod 1). Så, om du definierar: ```latex \\toks0={abcde} \\def\\mychars{abcde} ``` Och gör så här: ```latex \\uppercase\\expandafter{\\mychars} \\uppercase\\expandafter{\\the\\toks0} ``` i båda fallen kommer du nu att se ABCDE sättas om eftersom `\expandafter` orsakar ”uppackning” (expansion) av `\\mychars` och `\\the\\toks0`—båda resulterar i `\uppercase` att se en ström av teckentokens, vilka de kan bearbeta för att ändra skiftläge. ### Exempel 2: \\\string—fler tillfälliga tokenlistor Internt klassificerar TeX `\string` Det `\string` kommandot är utformat för att omvandla en token till en mänskligt läsbar textversion—dvs. sätta den mänskligt läsbara strängen av tecken som den token ursprungligen skapades från. Till exempel `\string\hello` skapar en tillfällig tokenlista som innehåller tecknen \\, h, e, l, l, o — ja, även med det inledande ‘\’. När den tokenlistan har skapats läses den sedan in igen av TeX och texten för kommandot “`\hello`” sätts—ja, inklusive ‘\’ om du väljer rätt typsnitt… Du kanske undrar hur/varför TeX kan sätta escape-tecknet när det vanligtvis används för att få TeX:s skanner att skapa en kommandotoken: varför gör den inte det här? Svaret har att göra med kategorikoder: normalt har tecknet ‘\’ catcode 0 (escape-tecken), men när `\string` genererar sin interna tokenlista gör den något lite annorlunda. När den skapar en lista av teckentokens tilldelar den kategorikod 12 till alla tecken utom mellanslagstecknet, som tilldelas catcode 10—kom ihåg att teckentokens beräknas från 256 x catcode + ASCII-värde. Så när TeX läser in (inputar) den tillfälliga tokenlistan som `\string` genererats från `\hello`, TeX *ser inte ett escape-tecken* eftersom tokenen för ‘\’ beräknades med catcode 12 och inte 0: TeX behandlar helt enkelt ‘\’ som ett vanligt tecken och sätter det. Strängt taget bör vi nog notera att TeX inte faktiskt genererar en token för escape-tecken när det upptäcker dem i indata. När det väl har identifierat ett tecken med kategorikod 0 används det tecknet bara för att ”utlösa” genereringen av en kontrollsekvens-token: när det har fått TeX att göra det har escape-tecknet gjort sitt arbete och beaktas inte längre. ### Teknisk anmärkning Ett kommando som heter `\showtokens{...}` (infört av e-TeX-motorn) kan visa tokenlistor (i loggfilen). Från e-TeX-manualen: > Kommandot `\showtokens{}` visar tokenlistan och möjliggör visning av sådana värden som inte kan visas av `\show` eller `\showthe`, t.ex.: > > ```latex > \showtokens\expandafter{\jobname} > ``` ## Sammanfattningsvis I avsnitt 291 i TeX-källkoden (se sidan 122 i [TeX: The Program](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373)) beskriver Knuth en tokenlista enligt följande: > “En tokenlista är en enkel-länkad lista av enordsnoder i mem, där varje ord innehåller en token och en länk. Makrodefinitioner, definitioner av utmatningsrutinen, markeringar, `\\write` texter, och några få andra saker, kommer TeX ihåg i form av tokenlistor, vanligtvis föregångna av en nod med en referensräknare i fältet ”token\_ref\_count”.” Vid första läsningen har detta kanske inte varit lätt att förstå men förhoppningsvis blir det nu lite mer begripligt. --- # 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/sv/fordjupade-artiklar/54-what-is-a-tex-token-list.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.