> 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/no/dybdeartikler/54-what-is-a-tex-token-list.md). # Hva er en TeX-tokenliste ## Så, hva er egentlig en "TeX-tokenliste"? I en [forrige artikkel](/latex/no/dybdeartikler/53-what-is-a-tex-token.md)—også en del av denne [serie om lavnivå-TeX-finesser](/latex/no/dybdeartikler/01-a-new-series-of-articles-tex-tokens-and-related-concepts-but-why-and-how.md)—utforsket vi prosessene som TeX skanner filen din gjennom for å generere nye tokens: `.tex` vi undersøkte den grunnleggende naturen til et TeX-token og hvordan TeX lager dem (se [Hva er et «TeX-token»?](/latex/no/dybdeartikler/53-what-is-a-tex-token.md)). I denne oppfølgingsartikkelen ser vi nærmere på *tokenliste*er: hva er de, og hvordan lager/bruke TeX-motorer dem. Det kan være vanskelig å få grep om tokenlister fordi de er lagret dypt inne i TeXs indre: disse detaljene er skjult for brukeren—selv om dette i dag ikke alltid er tilfelle hvis du driver mer avansert programmering med LuaTeX. Men foreløpig kan du begynne å tenke på tokenlister som TeXs måte å lagre en rekke heltallsverdier på, der hvert heltall er et token avledet fra et tegn eller en kommando som TeX har lest fra innmatingsfilen din. Tokenlister spiller en sentral rolle i den interne driften av TeX, ofte på noen overraskende måter, som i den interne driften av kommandoer som `\uppercase` og `\\lowercase`. En særlig viktig bruk av tokenlister er å lagre og utføre makroer, et tema vi skal undersøke i detalj som en del av en framtidig artikkel i denne serien. ### TeX får innholdet sitt fra filer og tokenlister TeX-motorer har tre kilder til input—to som du kanskje kjenner: * fysiske tekstfiler lagret på disken; * tekst som en bruker skriver inn i terminalen (kommandolinjen); men den har også en tredje måte å lese/få input på: tokenlister! Tokenlister er i praksis et internt datalagringsanlegg som TeX bruker som en del av driften. Fordi TeXs tokenlister fungerer som et "lagringsanlegg" for tidligere opprettede tokens, gir det mening at TeX kan gjenbruke dem som en annen inputkilde. Når det blir nødvendig å ta neste input fra en bestemt tokenliste (eller TeX blir instruert til å gjøre det), vil TeX midlertidig stanse lesingen av *nye tokens*) og bytte til å hente inputen sin fra *eksisterende tokens*: den plasseringen i minnet der tokenlisten er lagret. Tydeligvis har prosessen med å skanne + generere tokens allerede funnet sted med en tokenliste, så TeX trenger bare å se på hvert token i listen og bestemme hva den skal gjøre med hvert enkelt. Som et raskt eksempel kan den lavnivå- (TeX-primitive) `\toks` kommandoen la deg lage en liste over tokens som TeX lagrer i minnet for senere gjenbruk: ```latex \\toks100={Hello} ``` For å hente disse tokenene (dvs. be TeX behandle dem som sin neste inputkilde) ville du gitt en kommando som ```latex \the\toks100 ``` Dette vil få TeX til å bytte fra å lage nye tokens fra inputfilen din til å hente neste input fra der disse tokenene (opprettet av `\toks`) er lagret—i et såkalt *tokenregister* som bare er en intern minneplassering kjent for TeX (her er det register 100). I tillegg kan tokenlister genereres internt, on-the-fly, av en rekke TeX-kommandoer. Ett eksempel er kommandoen `\jobname` som genererer en rekke tegntokens—ett token for hvert tegn i navnet på hovedfilen som TeX behandler. Et annet eksempel er `\string` kommandoen; for eksempel ```latex \\string\\mymacro ``` genererer en rekke tegntokens for hver bokstav i navnet `\mymacro`—inkludert det innledende `\` tegnet. Vi ser nærmere på noen «token-genererende kommandoer» mot slutten av denne artikkelen. ## Tokenliste: forklart ved analogi Med mindre du har programmeringsbakgrunn og/eller noe kunnskap om informatikk, kan «tokenlister» være et noe uklart konsept, og kanskje litt forvirrende. Men hvis du ønsker å bli dyktig i å skrive TeX/LaTeX-makroer, vil en god forståelse av temaer som TeX-tokens, tokenlister og kategori-koder (`\catcode`) vise seg å være ekstremt nyttig. I denne delen skal vi bruke en analogi for å forklare/illustrere kjerneideene/prinsippene bak en TeX-tokenliste: hvordan TeX lagrer tokens i minnet. Det er verdt å bruke litt tid på å lese dette, fordi tokenlister er en *grunnleggende* aspekt ved TeX og verdt å forstå litt nærmere. ### Tokenlister: En analogi (tankeforsøk) Vi skal arbeide oss gjennom et «tankeforsøk» for å gi et grunnlag for å forstå TeX-tokenlister. Tenk deg at du hadde tilgang til et stort antall beholdere, som hundrevis av blikkbokser—vi kan ikke bruke ordet «boks» for å beskrive beholderne i tankeforsøket vårt fordi «boks» selvfølgelig har en helt spesifikk betydning i TeX, som er helt uavhengig av det vi diskuterer her. Så vi skal kalle beholderne våre «bokser», der hver boks: * har et unikt identifikasjonsnummer trykt på utsiden; * er (internt) delt i to rom. De to rommene er utformet slik: * det venstre rommet holder gjenstanden du vil legge i boksen; * det høyre rommet er laget for å holde et stykke papir som du kan skrive ett enkelt tall på: nummeret som identifiserer en annen boks. ![test](/files/6a79ec02c9133d8fe518019831d6d403c62ac2a9) Anta at du har en samling på for eksempel 5 gjenstander, og du vil lagre denne samlingen av gjenstander i disse boksene; men akk, hver boks kan bare holde 1 gjenstand av typen du ønsker å lagre. For enkelhets skyld antar vi at vi ønsker å lagre 5 fargede sirkler: ![{{{alt}}}](/files/6fc01922136c57473679333254d560414468b494) Videre, når du senere går tilbake for å hente disse gjenstandene fra lagringssystemet ditt (boksene), må gjenstandene *må* kunne hentes/finnes i en bestemt rekkefølge—rekkefølgen de ble lagret i: den sekvensen må bevares. Hvordan kan du oppnå dette? Vi kan dra nytte av det faktum at hver boks: * har et unikt identifikasjonsnummer festet på utsiden; * har 2 rom—bare 1 av dem vil vi bruke til å inneholde gjenstanden vår, det andre inneholder et stykke papir med nummeret til en annen boks skrevet på det. Vi antar at hver boks er tom—men ingenting hindrer deg i å åpne en bestemt boks for å sjekke om den er tom; hvis den ikke er det, prøv den neste til du finner en tom boks. Det vi kunne gjøre er som følger. Legg den første gjenstanden vår (mørkegrønn sirkel) i en av boksene våre (f.eks. boks 124) og noter nummeret til denne første boksen—det spiller ingen rolle hvilket nummer denne første boksen har, det eneste som betyr noe er at vi skriver det ned et sted og sparer det til senere bruk. ![{{{alt}}}](/files/fecbbc21d706b692676428759f972769511db7c2) Finn en annen boks—hvilket som helst boksnummer (f.eks. boks 432)—og noter nummeret. Skriv nummeret til denne andre boksen (432) på et stykke papir og legg den notaten *i den første boksen* (boks 124). Vi legger den andre gjenstanden vår (lysegrønn sirkel) i den andre boksen. Så vi har nå følgende situasjon: * en skriftlig notis—not lagret i en boks—som sier at den første boksen er nummer 124 (den inneholder den første gjenstanden vår); * inne i boks 124 har vi lagt til en annen notis som sier at neste gjenstand finnes i boks 432. I hovedsak har vi *koblet* de to første boksene våre sammen: vi vet hvor vi skal begynne (boks 124), og at en lapp i boks 124 forteller oss hvilken boks som inneholder neste gjenstand (boks 432). ![{{{alt}}}](/files/bc6f4e9e817f4b7e747edf89acd2ff23f59bae37) Deretter finner vi en tredje boks, skriver nummeret dens (f.eks. boks 543) på et stykke papir og legger det i den *andre* boksen (nummer 432). Deretter legger vi den tredje gjenstanden vår (rød sirkel) i den tredje boksen. Nå har vi koblet tre bokser sammen i sekvensen: startpunktet vårt, boks 124 (mørkegrønn sirkel) → boks 432 (lysegrønn sirkel)→ boks 543 (rød sirkel) →… ![{{{alt}}}](/files/b9500eee4c18a5d63cf54900ed947beee6c87b41) Gjenta denne prosessen for de to siste gjenstandene (lyseblå og mørkeblå sirkler) ved å bruke boks 213 (lyseblå sirkel) og boks 102 (mørkeblå sirkel). ![{{{alt}}}](/files/d59c69bf3ca03ea303a30b67e63d7e98811bc2ae) Vi har nå alle 5 boksene koblet sammen (ved hjelp av det numeriske identifikasjonsnummeret til hver boks) og kan hente alle de lagrede gjenstandene våre—i riktig rekkefølge—bare ved å besøke hver boks etter tur, ta ut gjenstanden vår og se på lappen som forteller oss hvilken boks som inneholder neste gjenstand. ### Hva med den siste gjenstanden i listen vår (boks 102)? Hvorfor bør vi være opptatt av akkurat denne? Så langt har vi lagret hver gjenstand i en boks, sammen med en lapp som sier hvilken boks som inneholder neste gjenstand: for den siste gjenstanden i listen vår, hva skal den lappen si—siden det ikke finnes noen neste boks. Når vi kommer til den siste gjenstanden (boksen), må det være tydelig at denne boksen (som inneholder den siste gjenstanden) er den siste gjenstanden i listen vår—vi trenger ikke lete etter en annen boks, fordi det finnes ingen. En måte å gjøre det på er å legge et «spesielt» boksnummer inni den siste boksen vår (102). Vi kan bruke hvilket som helst nummer vi vil, så lenge vi velger et unikt nummer som ikke er nummeret til en faktisk boks—for eksempel «boks -1», «boks 0»: det spiller ingen rolle så lenge vi vet at «boks -1» eller «boks 0» osv. umiddelbart forteller oss at vi skal slutte å lete: vi trenger ikke å lete etter flere bokser fordi dette er den siste, og dermed finnes det ingen flere gjenstander å hente. ### Fra «gjenstander» og «bokser» til tokens og TeX Vi må nå bevege oss fra analogien vår til en beskrivelse som ligger nærmere TeXs virkelighet. For det første, i stedet for å lagre sirkler i forskjellige farger i de tenkte boksene våre, bør det være klart at vi kan tenke på disse boksene som lagring av TeX-tokens: enkle heltall. Det er den enklere delen av å flytte analogien vår over i programvareverdenen (TeX). Men hva kan være den programvaremessige ekvivalenten til de fysiske nummererte boksene våre med «rom»? Vi vil ikke gå for langt inn i programmeringsbegreper, men du kan tenke på våre «bokser» som noen få byte dataminne som er blitt «pakket inn» i en praktisk lagringsenhet. I analogien vår kan det numeriske identifikasjonsnummeret for hver boks betraktes som plasseringen i dataminnet der hver lille minnepakke befinner seg. Inne i TeX selv kalles disse små lagringspakkene for «memory words»—et uttrykk som gjenspeiler tiden/æraen da TeX ble laget (1970-tallet). Disse «memory words» er den grunnleggende byggeblokken som brukes i TeX, men vi trenger ikke utforske dem mer i detalj her—alle som ønsker mer detaljer kan se en artikkel om [forfatterens personlige blogg](http://www.readytext.co.uk/?p=3537). I dataprogrammeringstermer kalles det vi har diskutert en [*lenket liste*](https://en.wikipedia.org/wiki/Linked_list): en TeX-tokenliste er en lenket liste bygget av TeXs lagringsbeholdere kalt *memory words* der hver memory word kan brukes til å lagre: * a *verdi*: verdien av tokenet (et heltall); * a *lenke*: minneplasseringen til neste memory word som inneholder det neste tokenet i listen vår. ## Hvor bruker TeX tokenlister? Overalt! Dette er sant fordi en TeX/LaTeX-makrodefinisjon (f.eks. en LaTeX-kommando) lagres som en (litt spesialisert) form for tokenliste—spesialisert i den forstand at den inneholder tokens du ikke ser i «standard» tokenlister (knyttet til matching av makroparametere osv.). Ikke bekymre deg for dette fordi vi skal ta for oss disse detaljene i en framtidig artikkel. ### Et eksempel på en makro En makro kan ses på som bestående av tre deler: ``` \\def\\{} ``` Merk at i stedet for `\def` kunne du ha brukt `\edef`, `\gdef` eller `\xdef`. **Merk til LaTeX-brukere**: Her definerer vi makroer ved hjelp av rå, lavnivå, TeX-kommandoer (kalt *primitivene*). LaTeX-brukere vil være mer kjent med å lage makroer via LaTeXs `\newcommand` (som i seg selv er en makro). Når du ber TeX om å lage (definere) en makro, vil den lage et token som representerer `` og en *tokenliste* som representerer den kombinerte `` og ``. TeX vil lagre alt nøye slik at tokenet som representerer `` er koblet til tokenlisten som representerer definisjonen dens (`` og ``). For eksempel, hvis vi definerer `\mymacro` slik: ```latex \\def\\mymacro abc #1 defz{I typed "#1"!} ``` Vi kan se at de bestanddelene er: * `` = `mymacro` * `` = `abc #1 defz` * `` = `I typed "#1"!` Du kan for eksempel kalle `\mymacro` slik: ```latex \\mymacro abc THIS TEXT defz ``` som resulterer i `I typed "THIS TEXT"!` blir satt— `abc` og `defz` er *inneholder* satt. `abc` og `defz` er sekvenser av tegn-tokens som brukes til å *avgrense* makroparameteren `#1` og blir absorbert og forkastet når makrokallet ditt behandles vellykket av TeX. Når du definerte `\mymacro`, fungerer mønsteret av tokens som finnes i den lagrede som en «mal» som TeX kan bruke til å finne ut: * hvilke tokens i inputen din som er skilletegn-tokens; * hvilke tokens i inputen din som faktisk utgjør parameteren(e) til makroen din (her, det du bruker for `#1` i kallene dine av `\mymacro`). Du må kalle `\mymacro` med en `` med skilletegn som er identiske med dem som ble brukt til å definere den—det inkluderer bruk av tegnskilletegn med identiske kategori-koder. Hvis skilletegnene i `` som brukes til å kalle `\mymacro` er forskjellige fra dem som ble brukt til å definere den («malen» lagret i minnet), kan TeX bli ganske forvirret—når den prøver å behandle `\mymacro` ville den ikke kunne matche «malen» den har lagret i minnet. Når TeX ser at du kaller en makro, vil den skanne inputteksten din for å lage nye tokens og prøve, token for token, å matche dem med tokenlisten `` malen som er lagret som del av makrodefinisjonen din. Hvis skilletegnene som brukes i inputteksten din resulterer i en rekke tokens som ikke matcher dem som er lagret i «malen», vil TeX vanligvis gi en feil. TeX er svært sær—husk at tegntokens er en kombinasjon av tegnkode og kategori-kode: hvis du endrer kategori-koden til et tegn, får du en annen tokenverdi fra det tegnet. Anta at vi endret kategori-koden til `z` til for eksempel 12—vanligvis er den 11—og prøv å kalle makroen vår slik: ```latex \\catcode`z=12 \\mymacro abc THIS TEXT defz more text here... ``` Denne gangen vil det ikke virke fordi kategori-koden til `z` har blitt endret. Du vil se en feil som denne: ```latex Runaway argument? THIS TEXT defz ! Paragraph ended before \\mymacro was complete. \par l.22 ``` Når TeX leser og skanner `z` i `defz` kan den ikke gjenkjenne den som å danne slutten på `\mymacro`s `` som ble brukt i inputfilen din. Fram til den feilaktige `z` hadde TeX korrekt matchet de første 3 tegnene `def` men det `z` (med kategori-kode 12) får TeXs skanning til å gå i stå. Hvis `z` hadde hatt kategori-koden 11 da vi *definerte* `\mymacro`: det ville resultere i at en tokenverdi på 256×11 + 122 = 2938 ble lagret som en del av `\mymacro`sin definisjon (dvs. lagret som en del av «malen»). Men med kategori-kode 12, `z` vil nå lage en tokenverdi på 256×12 + 122 = 3194. Fordi tokenverdien (for `z`) lest inn fra inputen din (verdi 3194) ikke samsvarer med `z`-tokenet som finnes i den lagrede `` tokenliste-malen (verdi 2938), vil TeX fortsette å skanne inputen din. TeX vil fortsette å skanne teksten som følger etter makroen din (*mer tekst her* ...) for å se etter flere tokens—og forsøke å matche den lagrede malen med tokenene den finner i inputen din. Den vil sannsynligvis ikke finne det riktige tokenmønsteret, og feil vil oppstå når TeX «overskyter» inputen din og feilaktig leser ekstra tekst for å lage flere tokens—disse ekstra tokenene skulle ikke ha blitt lest på dette tidspunktet og vil nesten helt sikkert generere en feil. Vi skal gå nærmere inn på dette i en framtidig artikkel. ## Andre bruksområder for tokenlister Andre kommandoer som brukes til å lage/lagre tokenlister inkluderer: ```latex \\toks={...} \\everypar={...} \\everymath={...} \\everydisplay={...} \\everyhbox={...} \\everyvbox={...} \\output={...} \\everyjob={...} \\everycr={...} \\errhelp={...} ``` Hver eneste av disse kommandoene lager en tokenliste fra tegnene og kommandoene innenfor klammeparentesene ‘{...}’, og denne listen over tokens er ment å kunne gjenbrukes under visse omstendigheter. For eksempel, `\\everypar={...}` oppretter og lagrer et sett med tokens (en tokenliste) som TeX injiserer i inputen rett før den starter et nytt avsnitt. ## Skjulte bruksområder for tokenlister: eksempler I denne siste delen skal vi se på noen praktiske eksempler på tokenlister som brukes på måter du kanskje ikke forventer. ### Eksempel 1: \\\uppercase{...} og \\\lowercase{....}—midlertidige tokenlister I tillegg til eksplisitte kommandoer for å generere tokenlister, finnes det situasjoner der TeX genererer en skjult og midlertidig intern tokenliste for å gjøre en spesiell behandling. Husk at når TeX leser/behandler inputtegnene/-kommandoene dine, blir de gjort om til tokens: den grunnleggende byggeblokken TeX-motorer arbeider med. Et godt eksempel er kommandoene `\uppercase{...}` eller `\\lowercase{...}` fordi virkemåten deres ved første møte kan være ganske forvirrende. Når du først forstår hva de gjør—dypere inne i TeX og usynlig for brukeren—blir virkemåten deres mye lettere å forstå. Anta at du har en enkel rekke bokstaver som du vil gjøre om til store bokstaver—f.eks. abcde og konvertere det til ABCDE. Vel, det er enkelt nok med TeXs `\uppercase` kommandoen: ```latex \\uppercase{abcde} ``` vil få TeX til å skrive ut `ABCDE`. La oss nå anta at vi ønsket å lagre den enkle bokstavrekken vår for senere bruk—dvs. vi vil ikke skrive den ut med en gang, så vi vil bruke TeXs eneste *interne* mekanisme—not en ekstern (fil-)mekanisme—for å lagre data: bruk en tokenliste. Vi kan gjøre det ved enten å opprette en makro eller bruke en eksplisitt tokenliste-kommando: ```latex \\toks100={abcde} \\def\\mychars{abcde} ``` Så kan du på et tidspunkt bestemme at du gjerne vil gjenbruke bokstavrekken din, men denne gangen i store bokstaver; så du prøver ```latex \\uppercase{\\the\\toks100} ``` og ```latex \\uppercase{\\mychars} ``` Men akk, ingen av disse fungerer. Hvorfor er det slik? ### Hemmelige tokenlister! For å forstå hvordan kommandoene `\uppercase{...}` `\\lowercase{...}` faktisk fungerer, måtte jeg titte inn i TeXs indre mekanismer, så forklaringen som følger er hentet derfra. Når TeX oppdager enten `\\uppercase{}` eller `\\lowercase{}` i inputen din, er det første TeX gjør å lage en (midlertidig) intern tokenliste fra `` innelukket mellom ‘{’ og ‘}’ som følger etter `\uppercase{...}` eller `\\lowercase{...}` kommandoene—den midlertidige tokenlisten er intern for TeX. Et avgjørende poeng, og sentralt for å forstå hvordan `\\uppercase{}` og `\\lowercase{}` faktisk fungerer, er at eventuelle kommandoer eller makroer som finnes i `` er ikke *ekspandert*: alt TeX gjør er å generere tokens fra tegn og kommandoer plassert mellom `{...}`. Under utførelsen av `\\uppercase{}` eller `\\lowercase{}` blir ingenting mellom klammeparentesene utført: det blir bare gjort om til tokens. Etter `` inne i `{...}` har blitt konvertert til en (midlertidig) tokenliste, går TeX deretter tilbake til hvert token i den listen og tester om det er et *tegnet* tegn-token eller et *kommandoen* kommando-token (ved å bruke den numeriske verdien til tokenet). Hvis TeX oppdager et tegn-token, modifiserer det tokenet for å justere tegnets store/lille bokstav (avhengig av om `\uppercase` eller `\\lowercase` behandles). TeX ignorerer ganske enkelt alle kommando-tokens og «ser ikke inn i» noen kommando-tokens for å se hva de representerer eller inneholder (f.eks. en makro som inneholder tegn)—de hoppes bare over: bare tegn-tokens blir faktisk behandlet/påvirket av operasjoner som endrer store/lille bokstaver. Så for eksempel, hvis vi gir en TeX-kommando som `\\uppercase{abcde}` TeX vil lage en tokenliste fra `abcde` som ikke inneholder noe annet enn tegn-tokens: de justeres alle for å lage en rekke modifiserte tokens som representerer A, B, C, D og E. Disse modifiserte tokenene mates tilbake inn i TeXs inputprosessor, som resulterer i `ABCDE` blir satt. Men hvis vi har lagret tegnene våre *inne i en makro*—for eksempel `\\def\\mychars{abcde}`—og prøver å konvertere dem til store bokstaver slik: ```latex \\uppercase{\\mychars} ``` så vil det mislykkes og abcde vil bli satt—not ABCDE som du kanskje forventer. Hvis vi deretter prøver å lagre tegnene våre i en tokenliste som `\\toks0={abcde}` og gjør `\\uppercase{\\the\\toks0}` så vil igjen `\uppercase` mislykkes fordi tokenlisten vil bestå utelukkende av tokens som ikke påvirkes av `\uppercase`. Tar vi eksemplet med makroen vår, `\\mychars`, etter at TeX oppdager `\uppercase` i inputen, slår TeX opp betydningen av `\uppercase` og utfører den, og oppretter en midlertidig tokenliste fra `{\\mychars}`. Tydeligvis inneholder den midlertidige tokenlisten bare ett token som ikke er et tegn-token, men et som representerer makrokommandoen vår `\\mychars`: derfor, med tanke på å utføre `\uppercase`, blir det tokenet ignorert—`\\mychars` representerer ikke et tegn-token. Men, som nevnt ovenfor, når `\uppercase` har gjort jobben sin, blir den midlertidige tokenlisten (opprettet av handlingen til `\uppercase`) matet tilbake inn i TeXs fulle inputbehandlingsmekanisme (skanning). Når TeX leser denne tokenlisten på nytt, oppdager den et token som representerer vår `\\mychars` makro, som TeX utfører (ekspanderer) og genererer en rekke tegn for å sette abcde—fortsatt i små bokstaver fordi de var «pakket inn» inne i en makro og dermed usynlige for handlingene til `\uppercase`. Når TeX har gransket den midlertidige tokenlisten som ble laget for `\uppercase{...}` eller `\\lowercase{...}`, og behandlet eventuelle tegn-tokens, bytter den deretter til å bruke den midlertidige tokenlisten som inputkilde: tegnsetting (behandlede tegn-tokens) og utførelse av kommandoer og makroer. ### Hvordan kan dette fikses? Siden `\uppercase{...}` eller `\\lowercase{...}` virker bare på tegn-tokens, trenger vi en måte å «tvinge utpakking» av tegnene som finnes i makroen vår `\\mychars` (eller som finnes i en `\toks` register) før `\uppercase{...}` eller `\\lowercase{...}` virker på den. Med «utpakking» mener vi egentlig TeXs prosess *utvidelse*: * å erstatte en TeX/LaTeX-kommando med *sekvensen* av tokens *som den kommandoen* (*f.eks. en makro*) *er bygget opp av,* eller * og produsere sekvensen av tokens en kommando er laget for å *generere*. Ett eksempel på en kommando som genererer tokens er `\jobname`, som produserer en sekvens av tegntokens som representerer navnet på hoved-TeX-filen som behandles. #### Lavnivå-magi: scantoks(..., ...) Her er vi virkelig inne og pirker i noen mørkere kroker av TeXs indre mekanismer, så du kan ignorere denne delen med mindre du liker detaljene… Etter at TeX oppdager `\uppercase` eller `\\lowercase` i inputstrømmen, utfører den en intern funksjon kalt `scantoks(..., ...)` hvis oppgave er å generere tokenlisten ved hjelp av elementene mellom den åpne ‘{’ og den lukkende ‘}’—som nevnt blir den tokenlisten deretter undersøkt for å oppdage (og så justere) eventuelle tegn-tokens for å endre tegnsettingen som kreves. Legg nøye merke til at vi her viser til `scantoks(..., ...)` som den interne funksjonen innebygd i kildekoden til TeX-motorer—her brukes det ikke som navnet på en kontrollsekvens. Som en del av arbeidet sitt, `scantoks(..., ...)` kan instrueres om hvorvidt den skal ekspandere, eller ikke ekspandere, tokenlisten den bygger, og for `\uppercase` og (`\\lowercase`) ekspanderer den ikke tokenene: den bare lager dem og legger dem inn i en tokenliste. En av de første tingene som `scantoks(..., ...)` må gjøre er å sjekke etter en åpning ‘{’ (eller et hvilket som helst tegn med `\catcode` 1) fordi den må forsikre seg om at brukeren ikke har gjort en syntaksfeil og glemt den åpne ‘{’ (eller et hvilket som helst tegn med kategori-kode 1)—fordi et tegn med kategori-kode 1 kreves for å markere starten på en liste med elementer som skal tokeniseres. Og her er trikset: oppgaven med å lete etter en åpning ‘{’ utløser `scantoks(..., ...)` til å kjøre TeXs ekspansjonsprosess, noe som betyr at følgende eksempler vil fungere: ```latex \\let\\ob={ \\uppercase\\ob abcde} \\def\\obb{\\ob} \\uppercase\\obb xyz} ``` Tar vi eksemplet med `\\obb`, en makro, blir den gjenkjent som en *utvidbar kommando* og blir behørig ekspandert av TeX (via `scantoks(..., ...)` funksjonen) i søket etter en åpningsklamme (et hvilket som helst tegn med kategori-kode 1). Det dette betyr er at vi kan bruke «`\expandafter` trikset» for å oppnå målet vårt om å «pakke ut» tegnene våre fra makroens begrensninger—dvs. ekspandere den. Merk at `\expandafter` også faller inn under kategorien av å være en *utvidbar kommando*, så TeX utfører den her og lar den gjøre jobben sin som del av jakten på en åpning ‘{’ (eller et hvilket som helst tegn med kategori-kode 1). Så, hvis du definerer: ```latex \\toks0={abcde} \\def\\mychars{abcde} ``` Og gjør dette: ```latex \\uppercase\\expandafter{\\mychars} \\uppercase\\expandafter{\\the\\toks0} ``` vil du i begge tilfeller nå se ABCDE satt, fordi `\expandafter` fører til «utpakking» (ekspansjon) av `\\mychars` og `\\the\\toks0`—begge resulterer i `\uppercase` å se en strøm av tegn-tokens, som de kan behandle for å endre store/lille bokstaver. ### Eksempel 2: \\\string—flere midlertidige tokenlister Internt klassifiserer TeX `\string` Det `\string` kommandoen er utformet for å konvertere en token til en lesbar tekstversjon – dvs. typesette den lesbare tegnstrengen som tokenet opprinnelig ble laget fra. For eksempel `\string\hello` oppretter en midlertidig tokenliste som inneholder tegnene \\, h, e, l, l, o — ja, til og med den innledende ‘\’. Når tokenlisten er opprettet, leses den deretter inn på nytt av TeX, og teksten til kommandoen “`\hello`” blir typesatt—ja, også ‘\’ hvis du velger riktig skrifttype… Du lurer kanskje på hvordan/hvorfor TeX kan typesette escape-tegnet når det vanligvis brukes til å få TeXs skanner til å lage et kommando-token: hvorfor gjør det ikke det her? Svaret har med kategorikoder å gjøre: vanligvis har et ‘\’-tegn kattekode 0 (escape-tegn), men når `\string` genererer sin interne tokenliste, gjør det noe litt annerledes. Når det lager en tegn-tokenliste, tildeler det kattekode 12 til alle tegn bortsett fra mellomromstegnet, som tildeles kattekode 10 — husk at tegn-tokens beregnes som 256 x kattekode + ASCII-verdi. Så når TeX leser (matar inn) den midlertidige tokenlisten som `\string` generert fra `\hello`, TeX *ser ikke et escape-tegn* fordi tokenet for ‘\’ ble beregnet med kattekode 12 og ikke 0: TeX behandler bare ‘\’ som et vanlig tegn og typesetter det. Strengt tatt bør vi nok merke oss at TeX faktisk ikke genererer et token for escape-tegn når det oppdager dem i innholdet. Når det først har gjenkjent et tegn med kategorikode 0, brukes dette tegnet bare til å «utløse» genereringen av et kontrollsekvens-token: når det først har fått TeX til å gjøre det, har escape-tegnet gjort jobben sin og blir ikke lenger tatt i betraktning. ### Teknisk merknad En kommando som heter `\showtokens{...}` (introdusert av e-TeX-motoren) kan vise tokenlister (i loggfilen). Fra e-TeX-manualen: > Kommandoen `\showtokens{}` viser tokenlisten og gjør det mulig å vise verdier som ikke kan vises av `\show` eller `\showthe`, f.eks.: > > ```latex > \showtokens\expandafter{\jobname} > ``` ## Til slutt I seksjon 291 av TeX-kildekoden (se side 122 i [TeX: The Program](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373)) beskriver Knuth en tokenliste slik: > “En tokenliste er en enkeltlenket liste av noder med ett ord i mem, der hvert ord inneholder et token og en lenke. Makrodefinisjoner, definisjoner av utdata-rutiner, merker, `\write` tekster, og noen få andre ting, huskes av TeX i form av tokenlister, vanligvis innledet av en node med en referansetelling i feltet “token\_ref\_count”.” Ved første lesning har dette kanskje ikke vært lett å forstå, men forhåpentligvis gir det nå litt mer mening. --- # 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/no/dybdeartikler/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.