> 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/pl/artykuly-szczegolowe/54-what-is-a-tex-token-list.md). # Czym jest lista tokenów TeX-a ## Czym właściwie jest „lista tokenów TeX-a”? W [poprzedni artykuł](/latex/pl/artykuly-szczegolowe/53-what-is-a-tex-token.md)—również część tego [serii o niskopoziomowych technikaliach TeX-a](/latex/pl/artykuly-szczegolowe/01-a-new-series-of-articles-tex-tokens-and-related-concepts-but-why-and-how.md)—badaliśmy procesy, przez które TeX skanuje twój `.tex` plik, aby generować nowe tokeny: przyjrzeliśmy się podstawowej naturze tokenu TeX-a i temu, jak TeX je tworzy (zob. [Czym jest „token TeX-a”?](/latex/pl/artykuly-szczegolowe/53-what-is-a-tex-token.md)). W tym artykule kontynuacyjnym przyjrzymy się *lista tokenów*: czym są i jak silniki TeX-a je tworzą/wykorzystują. Zrozumienie list tokenów może być trudne, ponieważ są one przechowywane głęboko wewnątrz TeX-a: te szczegóły są ukryte przed użytkownikiem — choć dziś nie zawsze jest to prawdą, jeśli wykonujesz bardziej zaawansowane programowanie w LuaTeX-u. Na razie możesz zacząć myśleć o listach tokenów jako o sposobie TeX-a na przechowywanie ciągu wartości całkowitych, gdzie każda liczba całkowita jest tokenem pochodzącym ze znaku lub polecenia, które TeX odczytał z twojego pliku wejściowego. Listy tokenów odgrywają kluczową rolę wewnętrznego działania TeX-a, często w zaskakujący sposób, na przykład w wewnętrznym działaniu poleceń takich jak `\uppercase` i `\lowercase`. Jednym z szczególnie ważnych zastosowań list tokenów jest przechowywanie i wykonywanie makr, a temat ten omówimy szczegółowo w przyszłym artykule z tej serii. ### TeX pobiera dane wejściowe z plików i list tokenów Silniki TeX-a mają trzy źródła danych wejściowych — dwa, które możesz znać: * fizyczne pliki tekstowe zapisane na dysku; * tekst wpisywany przez użytkownika do terminala (wiersza poleceń); ale ma też trzeci sposób odczytywania/pozyskiwania danych wejściowych: listy tokenów! Listy tokenów są w istocie wewnętrznym mechanizmem przechowywania danych, którego TeX używa jako części swoich operacji. Ponieważ listy tokenów TeX-a działają jako „magazyn” dla wcześniej utworzonych tokenów, ma sens, aby TeX mógł ponownie używać ich jako kolejnego źródła wejścia. Gdy staje się konieczne pobranie następnego wejścia z określonej listy tokenów (albo TeX zostaje do tego poinstruowany), TeX tymczasowo przestanie czytać dane z fizycznego pliku (tj. tworzyć *nowe tokeny*) i przełączy się na pobieranie danych wejściowych z *istniejących tokenów*: z pamięciowego miejsca, w którym przechowywana jest lista tokenów. Oczywiście, w przypadku listy tokenów proces skanowania + generowania tokenów już się odbył, więc TeX musi tylko spojrzeć na każdy token na liście i zdecydować, co z każdym z nich zrobić. Dla szybkiego przykładu, niskopoziomowe (prymityw TeX-a) `\toks` polecenie pozwala utworzyć listę tokenów, którą TeX zapisuje w pamięci do późniejszego ponownego użycia: ```latex \toks100={Hello} ``` Aby pobrać te tokeny (tj. powiedzieć TeX-owi, aby potraktował je jako następne źródło wejścia), wydasz polecenie takie jak ```latex \the\toks100 ``` Spowoduje to, że TeX przełączy się z tworzenia nowych tokenów z twojego pliku wejściowego na pobieranie następnych z miejsca, w którym są przechowywane te tokeny (utworzone przez `\toks`) — w tzw. *rejestru tokenów* —które jest po prostu wewnętrznym miejscem pamięci znanym TeX-owi (tutaj jest to rejestr 100). Ponadto listy tokenów mogą być generowane wewnętrznie, ad hoc, przez szereg poleceń TeX-a. Jednym z przykładów jest polecenie `\jobname` które generuje ciąg tokenów znakowych — po jednym tokenie dla każdego znaku w nazwie głównego pliku, który TeX przetwarza. Innym przykładem jest polecenie `\string` ; na przykład ```latex \string\mymacro ``` generuje ciąg tokenów znakowych dla każdej litery w nazwie `\mymacro`—włącznie z początkowym `\` znakiem. Na końcu tego artykułu przyjrzymy się bliżej kilku „poleceniom generującym tokeny”. ## Lista tokenów: wyjaśnienie przez analogię Jeśli nie masz doświadczenia programistycznego i/lub wiedzy z zakresu informatyki, „listy tokenów” mogą być nieco mętnym, a może nawet trochę mylącym pojęciem. Jeśli jednak chcesz opanować pisanie makr TeX/LaTeX, dobre zrozumienie takich tematów jak tokeny TeX-a, listy tokenów i kody kategorii (`\catcode`) okaże się niezwykle przydatne. W tej sekcji użyjemy analogii, aby wyjaśnić/zilustrować podstawowe idee/zasady listy tokenów TeX-a: jak TeX przechowuje tokeny w pamięci. Warto poświęcić chwilę, by to przeczytać, ponieważ listy tokenów są *fundamentalnym* aspektem TeX-a i warto je zrozumieć nieco dokładniej. ### Listy tokenów: analogia (eksperyment myślowy) Przeprowadzimy teraz „eksperyment myślowy”, aby stworzyć podstawę do zrozumienia list tokenów TeX-a. Wyobraź sobie, że masz dostęp do dużego zestawu pojemników, na przykład setek puszek — nie możemy użyć terminu „pudełko” do opisania pojemników z naszego eksperymentu myślowego, ponieważ oczywiście „box” ma w TeX-u bardzo specyficzne znaczenie, całkowicie niezwiązane z naszym omówieniem tutaj. Będziemy więc nazywać nasze pojemniki „puszkami”, przy czym każda puszka: * ma nadrukowany na zewnątrz unikalny numer identyfikacyjny; * jest (wewnętrznie) podzielona na dwie komory. Te dwie komory są zaprojektowane następująco: * lewa komora przechowuje element, który chcesz włożyć do puszki; * prawa komora jest przeznaczona na kawałek papieru, na którym możesz zapisać pojedynczą liczbę: numer identyfikujący inną puszkę. ![test](/files/42ad90feb1025cc3d5e66b8a57c803d52a89a96d) Załóżmy, że masz zbiór, powiedzmy, 5 elementów i chcesz przechować ten zbiór elementów w tych puszkach; ale niestety każda puszka może pomieścić tylko 1 element typu, który chcesz przechować. Dla uproszczenia załóżmy, że chcieliśmy przechować 5 kolorowych kół: ![{{{alt}}}](/files/39748100eab28c1dc71739cc44bca9f0b9e043e1) Ponadto, gdy wracasz, aby odzyskać te elementy ze swojego systemu przechowywania (puszek), elementy te *musi* muszą zostać pobrane/odnalezione w określonej kolejności — w kolejności, w jakiej zostały zapisane: ta sekwencja musi zostać zachowana. Jak można to osiągnąć? Możemy skorzystać z faktu, że każda puszka: * ma na zewnątrz przypięty unikalny numer identyfikacyjny; * ma 2 komory — z których tylko 1 wykorzystamy do przechowywania naszego elementu, a druga zawiera kawałek papieru z zapisanym numerem innej puszki. Załóżmy, że każda puszka jest pusta — ale nic nie stoi na przeszkodzie, by otworzyć dowolną puszkę i sprawdzić, czy jest pusta; jeśli nie jest, spróbuj następnej, aż znajdziesz pustą puszkę. Można to zrobić w następujący sposób. Włóż nasz pierwszy element (ciemnozielone koło) do jednej z puszek (np. puszki 124) i zanotuj numer tej pierwszej puszki — nie ma znaczenia, jaki numer ma ta pierwsza puszka, ważne jest tylko to, abyśmy zapisali go gdzieś i zachowali do późniejszego użycia. ![{{{alt}}}](/files/4742c4ad1f3ec0119b7dbb96960a8e556aee5e58) Znajdź drugą puszkę — dowolny numer puszki (np. puszka 432) — i zanotuj jej numer. Zapisz numer tej drugiej puszki (432) na kawałku papieru i włóż tę notatkę *do pierwszej puszki* (puszka 124). Wkładamy nasz drugi element (jasnozielone koło) do drugiej puszki. Zatem obecnie mamy następującą sytuację: * zapisana notatka — nieprzechowywana w puszce — stwierdzająca, że pierwsza puszka ma numer 124 (zawiera nasz pierwszy element); * w puszce 124 dodaliśmy kolejną notatkę mówiącą, że następny element można znaleźć w puszce 432. W istocie *połączyliśmy* nasze dwie pierwsze puszki: wiemy, gdzie zacząć (puszka 124) i że notatka w puszce 124 mówi nam, która puszka zawiera następny element (puszka 432). ![{{{alt}}}](/files/ad7721240fe7be1693f560541a945b3dc1213e57) Następnie znajdujemy trzecią puszkę, zapisujemy jej numer (np. puszka 543) na kawałku papieru i wkładamy to do *drugiej* puszki (numer 432). Następnie wkładamy nasz trzeci element (czerwone koło) do trzeciej puszki. Teraz połączyliśmy trzy puszki w sekwencję: nasz punkt startowy, puszka 124 (ciemnozielone koło) → puszka 432 (jasnozielone koło) → puszka 543 (czerwone koło) →… ![{{{alt}}}](/files/60a8fc47ebae88873292a6d4c4b06635356355d5) Powtórz ten proces dla dwóch ostatnich elementów (jasnoniebieskiego i ciemnoniebieskiego koła), używając puszki 213 (jasnoniebieskie koło) i puszki 102 (ciemnoniebieskie koło). ![{{{alt}}}](/files/9cdee7ee116c891e6c4fb0b413c5b2df32e14abb) Teraz mamy wszystkie 5 puszek połączonych ze sobą (za pomocą numerycznego identyfikatora każdej puszki) i możemy odzyskać wszystkie przechowywane elementy — we właściwej kolejności — po prostu odwiedzając kolejno każdą puszkę, wyjmując nasz element i odczytując notatkę mówiącą nam, która puszka zawiera nasz następny element. ### A co z ostatnim elementem na naszej liście (puszka 102)? Dlaczego mielibyśmy szczególnie się tym przejmować? Do tej pory przechowywaliśmy każdy element w puszce wraz z notatką mówiącą, która puszka zawiera następny element: dla ostatniego elementu na naszej liście co powinna mówić ta notatka — skoro nie ma następnej puszki. Gdy dochodzimy do ostatniego elementu (puszki), musi być oczywiste, że ta puszka (zawierająca ostatni element) jest ostatnim elementem na naszej liście — nie musimy szukać kolejnej puszki, bo jej nie ma. Jednym ze sposobów jest umieszczenie „specjalnego” numeru puszki wewnątrz naszej ostatniej puszki (102). Możemy użyć dowolnego numeru, pod warunkiem że wybierzemy unikalny numer, który nie jest numerem rzeczywistej puszki — na przykład „puszka -1”, „puszka 0”: nie ma to znaczenia, o ile wiemy, że „puszka -1” albo „puszka 0” itd. natychmiast oznacza dla nas, że mamy przestać szukać: nie musimy szukać więcej puszek, bo to ostatnia, a więc nie ma już kolejnych elementów do odzyskania. ### Od „elementów” i „puszek” do tokenów i TeX-a Musimy teraz przejść od naszej analogii do opisu bliższego rzeczywistości TeX-a. Po pierwsze, zamiast przechowywać różnokolorowe koła w naszych wyimaginowanych puszkach, powinno być jasne, że możemy myśleć o tych puszkach jako o przechowujących tokeny TeX-a: zwykłe liczby całkowite. To łatwiejsza część przenoszenia naszej analogii do świata oprogramowania (TeX-a). Ale czym mogłoby być odpowiednikiem programowym naszych fizycznych ponumerowanych puszek z „komorami”? Nie chcemy zbyt daleko wchodzić w pojęcia programistyczne, ale możesz myśleć o naszych „puszkach” jako o kilku bajtach pamięci komputera, które zostały „spakowane” w wygodną jednostkę przechowywania. Numeryczny identyfikator każdej puszki w naszej analogii można traktować jako lokalizację w pamięci komputera, gdzie znajduje się każda mała paczka pamięci. W samym TeX-u te małe paczki pamięci nazywane są „słowami pamięci” — terminem odzwierciedlającym czas/epokę, w której TeX został stworzony (lata 70.). Te „słowa pamięci” są podstawowym budulcem używanym w TeX-u, ale nie musimy tu zagłębiać się w nie bardziej — każdy, kto chce więcej szczegółów, może zajrzeć do artykułu na [osobistym blogu autora](http://www.readytext.co.uk/?p=3537). W terminach programowania komputerowego to, o czym właśnie rozmawialiśmy, nazywa się [*listą połączoną*](https://en.wikipedia.org/wiki/Linked_list): lista tokenów TeX-a to lista wiązana zbudowana z pojemników pamięci TeX-a zwanych *słowami pamięci* gdzie każde słowo pamięci może być użyte do przechowywania: * a *wartości*: wartości tokenu (liczby całkowitej); * a *łącza*: adresu pamięci następnego słowa pamięci zawierającego następny token na naszej liście. ## Gdzie TeX używa list tokenów? Wszędzie! To prawda, ponieważ definicja makra TeX/LaTeX (np. polecenie LaTeX) jest przechowywana jako (nieco wyspecjalizowana) forma listy tokenów — wyspecjalizowana w tym sensie, że zawiera tokeny, których nie widzisz w „standardowych” listach tokenów (związanych z dopasowywaniem parametrów makr itd.). Nie martw się tym, bo omówimy te szczegóły w przyszłym artykule. ### Przykładowe makro Makrę można uznać za składające się z trzech części: ``` \def\{} ``` Zauważ, że zamiast `\def` mogłeś użyć `\edef`, `\gdef` lub `\xdef`. **Uwaga dla użytkowników LaTeX-a**: Tutaj definiujemy makra za pomocą surowych, niskopoziomowych poleceń TeX-a (zwanych *prymitywów*). Użytkownicy LaTeX-a będą bardziej zaznajomieni z tworzeniem makr poprzez `\newcommand` LaTeX-owe \newcommand (które samo jest makrem). `` i *lista tokenów* Gdy prosisz TeX o utworzenie (zdefiniowanie) makra, utworzy on token, który reprezentuje `` i ``który reprezentuje połączony `` . TeX starannie zapisze wszystko tak, aby token reprezentujący`` i ``). Na przykład, jeśli zdefiniujemy `\mymacro` w ten sposób: ```latex \def\mymacro abc #1 defz{Napisałem "#1"!} ``` Możemy zobaczyć, że jego składowe części to: * `` = `mymacro` * `` = `abc #1 defz` * `` = `Napisałem "#1"!` Na przykład możesz wywołać `\mymacro` w ten sposób: ```latex \mymacro abc TEN TEKST defz ``` co skutkuje `Napisałem "TEN TEKST"!` złożonym tekstem — `abc` i `defz` jesteś *nie* złożonym tekstem. `abc` i `defz` to ciągi tokenów znakowych używane do *wyznaczania granic* parametru makra `#1` i są pochłaniane oraz odrzucane, gdy wywołanie makra zostanie pomyślnie przetworzone przez TeX. Kiedy zdefiniowałeś `\mymacro`, wzorzec tokenów zawarty w przechowywanym działa jako „szablon”, którego TeX może użyć do ustalenia: * które tokeny w twoim wejściu są tokenami ograniczającymi; * które tokeny w twoim wejściu faktycznie tworzą parametr(y) twojego makra (tutaj to, czego używasz dla `#1` w wywołaniu `\mymacro`). Musisz wywołać `\mymacro` przez `` zawierające ograniczniki identyczne z tymi, które zostały użyte do jego zdefiniowania — w tym użycie ograniczników znakowych o identycznych kodach kategorii. Jeśli ograniczniki w `` użyte do wywołania `\mymacro` różnią się od tych użytych do jego zdefiniowania („szablonu” przechowywanego w pamięci), TeX może się dość mocno pogubić — gdy spróbuje przetworzyć `\mymacro` nie byłby w stanie dopasować „szablonu”, który zapisał w swojej pamięci. Gdy TeX widzi, że wywołujesz makro, skanuje twój tekst wejściowy, aby utworzyć nowe tokeny i próbuje, token po tokenie, dopasować je do listy tokenów `` szablonu przechowywanego jako część definicji twojego makra. Jeśli ograniczniki użyte w twoim tekście wejściowym dają ciąg tokenów, który nie pasuje do tych zapisanych w „szablonie”, TeX zwykle zgłosi błąd. TeX jest bardzo skrupulatny — pamiętaj, że tokeny znakowe są połączeniem kodu znaku i kodu kategorii: jeśli zmienisz kod kategorii znaku, otrzymasz inną wartość tokenu wynikającą z tego znaku. Załóżmy, że zmieniliśmy kod kategorii `z` na, powiedzmy, 12 — zwykle jest to 11 — i spróbowali wywołać nasze makro w ten sposób: ```latex \catcode`z=12 \mymacro abc THIS TEXT defz more text here... ``` Tym razem to nie zadziała, ponieważ kod kategorii `z` został zmieniony. Zobaczysz taki błąd: ```latex Ucieczkowy argument? THIS TEXT defz ! Akapit zakończył się, zanim \mymacro został ukończony. \par l.22 ``` Gdy TeX czyta i skanuje `z` % `defz` nie może rozpoznać tego jako końca `\mymacro`jego `` użytego w twoim pliku wejściowym. Aż do napotkania tego błędnego `z` TeX poprawnie dopasował pierwsze 3 znaki `def` ale ten `z` (z kodem kategorii 12) zakłóca skanowanie TeX-a. Zakładając, że `z` miało kod kategorii 11, kiedy my *zdefiniowaliśmy* `\mymacro`: oznaczałoby to zapisanie wartości tokenu 256×11 + 122 = 2938 jako części definicji `\mymacro`(tj. zapisanej jako część „szablonu”). Jednak przy kodzie kategorii 12, `z` utworzy teraz wartość tokenu 256×12 + 122 = 3194. Ponieważ wartość tokenu (dla `z`) odczytana z twojego wejścia (wartość 3194) nie pasuje do `z`-tokenu zawartego w przechowywanym `` szablonie listy tokenów (wartość 2938), TeX będzie kontynuował skanowanie twojego wejścia. TeX będzie nadal skanował tekst następujący po twoim makrze (*more text here* ...) w poszukiwaniu dodatkowych tokenów — próbując dopasować zapisany szablon do tokenów, które znajdzie w twoim wejściu. Prawdopodobnie nie znajdzie poprawnego wzorca tokenów i pojawią się błędy, gdy TeX „przekroczy” twoje wejście i błędnie odczyta dodatkowy tekst, tworząc kolejne tokeny — tych dodatkowych tokenów nie powinno się było odczytać na tym etapie i niemal na pewno wygenerują błąd. Omówimy to bardziej szczegółowo w przyszłym artykule. ## Inne zastosowania list tokenów Inne polecenia służące do tworzenia/przechowywania list tokenów obejmują: ```latex \toks={...} \everypar={...} \everymath={...} \everydisplay={...} \everyhbox={...} \everyvbox={...} \output={...} \everyjob={...} \everycr={...} \errhelp={...} ``` Każde z tych poleceń tworzy listę tokenów ze znaków i poleceń wewnątrz nawiasów klamrowych „{...}”, a ta lista tokenów ma być ponownie używana w określonych okolicznościach. Na przykład `\everypar={...}` tworzy i przechowuje zestaw tokenów (listę tokenów), który TeX wstawia do wejścia tuż przed rozpoczęciem nowego akapitu. ## Ukryte zastosowania list tokenów: przykłady W tej ostatniej sekcji przyjrzymy się kilku praktycznym przykładom użycia list tokenów w sposób, którego możesz się nie spodziewać. ### Przykład 1: \uppercase{...} i \lowercase{....} — tymczasowe listy tokenów Oprócz jawnych poleceń generujących listy tokenów, istnieją sytuacje, w których TeX tworzy ukrytą i tymczasową wewnętrzną listę tokenów, aby wykonać specjalne przetwarzanie. Pamiętaj, że gdy TeX odczytuje/przetwarza twoje znaki/polecenia wejściowe, są one zamieniane na tokeny: podstawowy budulec, z którym pracują silniki TeX-a. Dobrymi przykładami są polecenia `\uppercase{...}` lub `\lowercase{...}` ponieważ ich działanie może na pierwszy rzut oka być dość mylące. Gdy zrozumiesz, co robią — głębiej wewnątrz TeX-a i niewidoczne dla użytkownika — ich działanie staje się znacznie łatwiejsze do pojęcia. Załóżmy, że masz prosty ciąg liter, które chcesz zamienić na wielkie — np. abcde i przekształcić to w ABCDE. Cóż, to proste z TeX-owym `\uppercase` polecenia: ```latex \uppercase{abcde} ``` spowoduje, że TeX wypisze `ABCDE`. Załóżmy teraz, że chcielibyśmy zachować nasz prosty ciąg liter do późniejszego użycia — tj. nie chcemy wypisywać ich od razu, więc użyjemy jedynego *wewnętrznego* mechanizmu — nie zewnętrznego (plikowego) — do zapisywania danych: użyj listy tokenów. Możemy to zrobić albo tworząc makro, albo używając jawnego polecenia listy tokenów: ```latex \toks100={abcde} \def\mychars{abcde} ``` Następnie w pewnym momencie możesz zdecydować, że chciałbyś ponownie użyć swojego ciągu liter, ale tym razem wielkimi literami; więc próbujesz ```latex \uppercase{\the\toks100} ``` i ```latex \uppercase{\mychars} ``` Ale niestety żadne z tych nie działa. Dlaczego? ### Tajne listy tokenów! Aby zrozumieć, jak naprawdę działają polecenia `\uppercase{...}` `\lowercase{...}` musiałem zajrzeć do wnętrza TeX-a, więc poniższe wyjaśnienie pochodzi właśnie stamtąd. Gdy TeX wykryje albo `\uppercase{}` lub `\lowercase{}` w twoim wejściu, pierwszą rzeczą, jaką robi TeX, jest utworzenie (tymczasowej) wewnętrznej listy tokenów z `` zamkniętego między „{” i „}”, które występują po `\uppercase{...}` lub `\lowercase{...}` poleceniach — ta tymczasowa lista tokenów jest wewnętrzna dla TeX-a. Kluczowy punkt, centralny dla zrozumienia, jak `\uppercase{}` i `\lowercase{}` naprawdę działają, jest taki, że wszelkie polecenia lub makra zawarte w `` nie są *rozwinięty*: wszystko, co TeX robi, to generowanie tokenów ze znaków i poleceń umieszczonych między `{...}`. Podczas działania `\uppercase{}` lub `\lowercase{}` nic pomiędzy nawiasami klamrowymi nie jest wykonywane: po prostu zamienia się to na tokeny. Po `` wewnątrz `{...}` zostało przekształcone w (tymczasową) listę tokenów, TeX następnie ponownie odwiedza każdy token na tej liście i sprawdza, czy jest to *znaku* token znakowy czy *polecenie* token polecenia `\uppercase` lub `\lowercase` (korzystając z wartości numerycznej tokenu). Jeśli TeX wykryje token znakowy, modyfikuje ten token, aby dostosować wielkość litery znaku (w zależności od tego, czy Na przykład, jeśli wydamy polecenie TeX-a takie jak `\uppercase{abcde}` TeX utworzy listę tokenów z `abcde` zawierającą nic poza tokenami znakowymi: wszystkie zostaną odpowiednio zmodyfikowane, aby utworzyć ciąg zmodyfikowanych tokenów reprezentujących A, B, C, D i E. Te zmodyfikowane tokeny są odsyłane z powrotem do procesora wejścia TeX-a, co skutkuje `ABCDE` złożeniem tekstu. Jednak jeśli przechowaliśmy nasze znaki *w makrze*—na przykład `\def\mychars{abcde}`—i spróbujemy zamienić je na wielkie litery w ten sposób: ```latex \uppercase{\mychars} ``` to zakończy się to niepowodzeniem i zostanie złożone abcde — nie ABCDE, jak można by się spodziewać. Jeśli następnie spróbujemy przechować nasze znaki w liście tokenów, takiej jak `\toks0={abcde}` i zrobimy `\uppercase{\the\toks0}` to znów `\uppercase` się nie powiedzie, ponieważ lista tokenów będzie składać się wyłącznie z tokenów, na które nie wpływa `\uppercase`. Biorąc przykład naszego makra, `\mychars`, po wykryciu `\uppercase` w wejściu, TeX sprawdza znaczenie `\uppercase` i wykonuje je, tworząc tymczasową listę tokenów z `{\mychars}`. Oczywiście ta tymczasowa lista tokenów zawiera tylko jeden token, który nie jest tokenem znakowym, lecz reprezentuje nasze polecenie makra `\mychars`: zatem na potrzeby wykonywania `\uppercase`, ten token jest ignorowany —`\mychars` nie reprezentuje tokenu znakowego. Jednak, jak zauważono wyżej, gdy `\uppercase` wykona swoje zadanie, tymczasowa lista tokenów (utworzona przez działanie `\uppercase`) jest odsyłana z powrotem do pełnego mechanizmu przetwarzania wejścia (skanowania) TeX-a. Gdy TeX ponownie odczytuje tę listę tokenów, wykrywa token reprezentujący nasze `\mychars` makro, które TeX rozwija (ekspanduje) i generuje ciąg znaków do złożenia abcde — nadal małych liter, ponieważ zostały one „zawinięte” w makro, a więc były niewidoczne dla działań `\uppercase`. Gdy TeX ponownie przeanalizuje tymczasową listę tokenów utworzoną dla `\uppercase{...}` lub `\lowercase{...}`, i przetworzy wszelkie tokeny znakowe, przełącza się następnie na używanie tej tymczasowej listy tokenów jako źródła wejścia: składając znaki (przetworzone tokeny znakowe) i wykonując polecenia oraz makra. ### Jak można to naprawić? Ponieważ `\uppercase{...}` lub `\lowercase{...}` zadziała tylko na tokenach znakowych, potrzebujemy sposobu, by „wymusić rozpakowanie” znaków zawartych w naszym makrze `\mychars` (lub zawartych w `\toks` rejestrze) `\uppercase{...}` lub `\lowercase{...}` zanim *rozwijanie*: * zastąpi polecenie TeX/LaTeX przez *ciąg* tokenów *z których to polecenie* (*np. makro*) *się składa,* lub * tworząc ciąg tokenów, które polecenie ma za zadanie *wygenerować*. Jednym z przykładów polecenia generującego tokeny jest `\jobname`, które tworzy ciąg tokenów znakowych reprezentujących nazwę głównego pliku TeX-a, który jest przetwarzany. #### Niskopoziomowa magia: scantoks(..., ...) Tutaj naprawdę zaglądamy do mroczniejszych zakamarków wewnętrznego działania TeX-a, więc możesz pominąć tę sekcję, chyba że lubisz takie szczegóły… Po wykryciu przez TeX `\uppercase` lub `\lowercase` w strumieniu wejściowym, wykonuje on wewnętrzną funkcję zwaną `scantoks(..., ...)` której zadaniem jest wygenerowanie listy tokenów z elementów znajdujących się między otwierającym „{” a zamykającym „}” — jak wspomniano, ta lista tokenów jest następnie analizowana w celu wykrycia (a potem dostosowania) wszelkich tokenów znakowych, aby zmienić wielkość liter zgodnie z potrzebą. Zwróć uważnie uwagę, że odnosimy się do `scantoks(..., ...)` jako do wewnętrznej funkcji wbudowanej w kod źródłowy silników TeX-a — tutaj nie chodzi o nazwę sekwencji sterującej. W ramach swojej pracy, `scantoks(..., ...)` można poinstruować, czy ma rozwijać, czy nie rozwijać, tworzoną przez siebie listę tokenów, a dla `\uppercase` i (`\lowercase`) nie rozwija tokenów: po prostu je tworzy i umieszcza na liście tokenów. Jedną z pierwszych rzeczy, które `scantoks(..., ...)` musi zrobić, jest sprawdzenie otwierającego „{” (lub dowolnego znaku o `\catcode` 1) ponieważ musi upewnić się, że użytkownik nie popełnił błędu składniowego i nie zapomniał o otwierającym „{” (lub dowolnym znaku o kodzie kategorii 1) — ponieważ znak o kodzie kategorii 1 jest wymagany do wyznaczenia początku listy elementów, które mają zostać przekształcone w tokeny. A oto sztuczka: zadanie szukania otwierającego „{” uruchamia `scantoks(..., ...)` proces ekspansji TeX-a, co oznacza, że następujące przykłady będą działać: ```latex \let\ob={ \uppercase\ob abcde} \def\obb{\ob} \uppercase\obb xyz} ``` Biorąc przykład `\obb`, makra, jest ono rozpoznawane jako *rozwijalnym poleceniem* token rozwijany `scantoks(..., ...)` i zostaje odpowiednio rozwinięte przez TeX (za pomocą funkcji`\expandafter` w poszukiwaniu otwierającego nawiasu klamrowego (dowolnego znaku o kodzie kategorii 1). Oznacza to, że możemy użyć „ `\expandafter` sztuczki” do osiągnięcia naszego celu „rozpakowania” znaków z ograniczeń naszego makra — tj. jego rozwinięcia. Zauważ, że *rozwijalnym poleceniem*również mieści się w kategorii Jeśli więc zdefiniujesz: ```latex \toks0={abcde} \def\mychars{abcde} ``` I zrobisz to: ```latex \uppercase\expandafter{\mychars} \uppercase\expandafter{\the\toks0} ``` w obu przypadkach zobaczysz teraz złożone ABCDE, ponieważ `\expandafter` powoduje „rozpakowanie” (ekspansję) `\mychars` i `\the\toks0`—obie dają `\uppercase` strumień tokenów znakowych, które mogą przetworzyć, aby zmienić wielkość liter. ### Przykład 2: \string — więcej tymczasowych list tokenów Wewnętrznie TeX klasyfikuje `\string` jako jedno ze swoich tak zwanych poleceń „convert”: wykonujące operację „zamień na tekst”. The `\string` Polecenie zostało zaprojektowane do konwertowania tokenu na czytelną dla człowieka wersję tekstową — tj. składania czytelnego dla człowieka ciągu znaków, z którego ten token został pierwotnie utworzony. Na przykład `\string\hello` tworzy tymczasową listę tokenów, która zawiera znaki \\, h, e, l, l, o — tak, nawet łącznie z początkowym „\”. Gdy tylko ta lista tokenów zostanie utworzona, TeX odczytuje ją ponownie, a tekst polecenia „`\hello`” jest składany — tak, łącznie z „\”, jeśli wybierzesz odpowiednią czcionkę… Możesz się zastanawiać, jak/dlaczego TeX może składać znak ucieczki, skoro zwykle służy on do uruchamiania skanera TeX-a, aby utworzył token polecenia: dlaczego nie robi tego tutaj? Odpowiedź ma związek z kodami kategorii: zwykle znak „\” ma catcode 0 (znak ucieczki), ale kiedy `\string` generuje swoją wewnętrzną listę tokenów, robi coś nieco innego. Gdy tworzy listę tokenów znakowych, przypisuje kod kategorii 12 wszystkim znakom z wyjątkiem znaku spacji, któremu przypisuje catcode 10 — przypomnijmy, że tokeny znakowe są obliczane jako 256 x catcode + wartość ASCII. Tak więc, gdy TeX ponownie odczytuje (wczytuje) tymczasową listę tokenów, którą `\string` została wygenerowana z `\hello`, TeX *nie widzi znaku ucieczki* ponieważ token dla „\” został obliczony z catcode 12, a nie 0: TeX po prostu traktuje „\” jako zwykły znak i go składa. Ściśle rzecz biorąc, powinniśmy chyba zauważyć, że TeX tak naprawdę nie generuje tokenu dla znaków ucieczki, gdy wykrywa je w wejściu. Gdy tylko rozpozna znak o kodzie kategorii 0, znak ten służy jedynie do „uruchomienia” generowania tokenu sekwencji sterującej: kiedy już uruchomi TeX do tego działania, znak ucieczki spełnił swoje zadanie i nie jest już brany pod uwagę. ### Uwaga techniczna Polecenie o nazwie `\showtokens{...}` (wprowadzone przez silnik e-TeX) może wyświetlać listy tokenów (w pliku dziennika). Z podręcznika e-TeX: > Polecenie `\showtokens{}` wyświetla listę tokenów i pozwala wyświetlać wielkości, których nie można wyświetlić za pomocą `\show` lub `\showthe`, np.: > > ```latex > \showtokens\expandafter{\jobname} > ``` ## Podsumowując W sekcji 291 kodu źródłowego TeX-a (zob. strona 122 książki [TeX: The Program](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373)) Knuth opisuje listę tokenów następująco: > „Lista tokenów jest pojedynczo połączoną listą węzłów jednosłownych w mem, gdzie każde słowo zawiera token i wskaźnik. `\write` Definicje makr, definicje procedury wyjściowej, znaczniki, teksty i kilka innych rzeczy są przez TeX-a zapamiętywane w formie list tokenów, zwykle poprzedzonych węzłem z licznikiem referencji w jego polu „token\_ref\_count”.” Przy pierwszym czytaniu mogło to nie być łatwe do zrozumienia, ale miejmy nadzieję, że teraz ma to trochę więcej sensu. --- # 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/pl/artykuly-szczegolowe/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.