> 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/overleaf-learn-latex-pt/artigos-aprofundados/54-what-is-a-tex-token-list.md). # O que é uma lista de tokens TeX ## Então, afinal o que é uma "lista de tokens TeX"? Num [artigo anterior](/latex/overleaf-learn-latex-pt/artigos-aprofundados/53-what-is-a-tex-token.md)—também parte desta [série sobre tecnicalidades de baixo nível do TeX](/latex/overleaf-learn-latex-pt/artigos-aprofundados/01-a-new-series-of-articles-tex-tokens-and-related-concepts-but-why-and-how.md)—explorámos os processos pelos quais o TeX analisa o seu `.tex` ficheiro para gerar novos tokens: examinámos a natureza fundamental de um token TeX e como o TeX os cria (ver [O que é um "token TeX"?](/latex/overleaf-learn-latex-pt/artigos-aprofundados/53-what-is-a-tex-token.md)). Neste artigo de seguimento, vamos analisar *lista de tokens*s: o que são e como os motores TeX os criam/usam. Compreender listas de tokens pode ser complicado porque são armazenadas nas partes internas do TeX: esses detalhes ficam ocultos ao utilizador — embora, hoje em dia, isso nem sempre seja verdade se fizer programação mais avançada com LuaTeX. Mas, por agora, pode começar a pensar nas listas de tokens como a forma do TeX armazenar uma série de valores inteiros, em que cada inteiro é um token derivado de um carácter ou comando que o TeX leu do seu ficheiro de entrada. As listas de tokens desempenham um papel fundamental no funcionamento interno do TeX, muitas vezes de formas surpreendentes, como no funcionamento interno de comandos como `\uppercase` e `\lowercase`. Um uso particularmente importante de listas de tokens é armazenar e executar macros, um tema que examinaremos em detalhe num artigo futuro desta série. ### O TeX obtém a sua entrada de ficheiros e listas de tokens Os motores TeX têm três fontes de entrada — duas que talvez conheça: * ficheiros de texto físicos armazenados em disco; * texto que um utilizador escreve no terminal (linha de comandos); mas também tem uma terceira forma de ler/obter entrada: listas de tokens! As listas de tokens são, na prática, uma instalação interna de armazenamento de dados que o TeX usa como parte das suas operações. Como as listas de tokens do TeX funcionam como uma “instalação de armazenamento” para tokens criados anteriormente, faz sentido que o TeX as possa reutilizar como outra fonte de entrada. Quando for necessário obter a próxima entrada a partir de uma determinada lista de tokens (ou quando o TeX for instruído a fazê-lo), o TeX interromperá temporariamente a leitura de entrada de um ficheiro físico (ou seja, a criação *de novos tokens*) e passará a obter a sua entrada de *tokens existentes*: a localização na memória onde a lista de tokens está armazenada. É evidente que, com uma lista de tokens, o processo de análise + geração de tokens já ocorreu, por isso o TeX só precisa de olhar para cada token da lista e decidir o que fazer com cada um. Como exemplo rápido, o comando primitivo (de baixo nível do TeX) `\toks` permite criar uma lista de tokens que o TeX guarda na memória para reutilização posterior: ```latex \toks100={Hello} ``` Para recuperar esses tokens (isto é, dizer ao TeX para os tratar como a sua próxima fonte de entrada), emitir-se-ia um comando como ```latex \the\toks100 ``` Isto fará com que o TeX mude de criar novos tokens a partir do seu ficheiro de entrada para obter os próximos de onde esses tokens (criados por `\toks`) estão armazenados — num chamado *registo de tokens* que é apenas uma localização de memória interna conhecida pelo TeX (aqui é o registo 100). Além disso, as listas de tokens podem ser geradas internamente, de forma dinâmica, por vários comandos TeX. Um exemplo é o comando `\jobname` que gera uma série de tokens de carácter — um token por cada carácter no nome do ficheiro principal que o TeX está a processar. Outro exemplo é o comando `\string` ; por exemplo ```latex \string\mymacro ``` gera uma série de tokens de carácter para cada letra do nome `\mymacro`—incluindo o carácter `\` inicial. No final deste artigo, analisamos mais de perto alguns “comandos geradores de tokens”. ## Lista de tokens: explicada por analogia A menos que tenha formação em programação e/ou algum conhecimento de ciência da computação, “listas de tokens” pode ser um conceito um tanto vago e, talvez, um pouco confuso. No entanto, se quiser tornar-se proficiente na escrita de macros TeX/LaTeX, então uma boa compreensão de temas como tokens TeX, listas de tokens e códigos de categoria (`\catcode`) será extremamente útil. Nesta secção vamos usar uma analogia para explicar/ilustrar as ideias/princípios centrais de uma lista de tokens TeX: como o TeX armazena tokens na memória. Vale a pena dedicar algum tempo a ler isto, porque as listas de tokens são um *aspeto* fundamental do TeX e merecem ser compreendidas com um pouco mais de detalhe. ### Listas de tokens: uma analogia (experiência mental) Vamos trabalhar através de uma “experiência mental” para fornecer uma base para compreender as listas de tokens TeX. Imagine que tinha acesso a um grande conjunto de recipientes, como centenas de latas — não podemos considerar ou usar o termo “caixa” para descrever os recipientes da nossa experiência mental porque, claro, “caixa” tem um significado muito específico no TeX, sem relação com a nossa discussão aqui. Por isso, vamos chamar aos nossos recipientes “Latas”, em que cada Lata: * tem um número de identificação único impresso no exterior; * está dividida (internamente) em dois compartimentos. Esses dois compartimentos são concebidos da seguinte forma: * o compartimento da esquerda contém o item que quer colocar na Lata; * o compartimento da direita foi concebido para conter um pedaço de papel no qual pode escrever um único número: o número que identifica outra Lata. ![teste](/files/524f74df34c6df98061593ecc76eecb2c87e714d) Suponha que tem uma coleção de, digamos, 5 itens e quer armazenar essa coleção de itens dentro dessas Latas; mas, infelizmente, cada Lata só pode conter 1 item do tipo que quer armazenar. Para simplificar, vamos assumir que queríamos armazenar 5 círculos coloridos: ![{{{alt}}}](/files/36f86e4f4896ddaeddc3ee41a96e27d36cf57863) Além disso, quando volta para recuperar esses itens do seu sistema de armazenamento (Latas), esses itens *deve* devem ser recuperados/encontrados numa ordem específica — a ordem em que foram armazenados: essa sequência tem de ser preservada. Como pode conseguir isso? Podemos tirar partido do facto de que cada Lata: * tem um número de identificação único afixado no exterior; * tem 2 compartimentos — dos quais só usaremos 1 para conter o nosso item, o outro contém um pedaço de papel com o número de outra Lata escrito nele. Vamos assumir que cada Lata está vazia — mas nada o impede de abrir qualquer Lata em particular para verificar se está vazia; se não estiver, tente a seguinte até encontrar uma Lata vazia. O que poderíamos fazer é o seguinte. Colocar o nosso primeiro item (círculo verde escuro) numa das nossas Latas (por exemplo, Lata 124) e anotar o número desta primeira Lata — não importa que número tenha essa primeira Lata, o que importa é que o escrevamos algures e o guardemos para uso posterior. ![{{{alt}}}](/files/9fdee4ac09c4bb2118f53fd8cd66f90b9777ccf3) Encontrar uma segunda Lata — qualquer número de Lata (por exemplo, Lata 432) — e anotar o seu número. Escrever o número dessa segunda Lata (432) num pedaço de papel e colocar essa nota *na primeira Lata* (Lata 124). Colocamos o nosso segundo item (círculo verde claro) na segunda Lata. Portanto, neste momento temos a seguinte situação: * uma nota escrita — não guardada numa Lata — indicando que a primeira Lata é a número 124 (contém o nosso primeiro item); * na Lata 124 adicionámos outra nota a dizer que o próximo item se encontra na Lata 432. Em essência, temos *ligado* as nossas duas primeiras Latas: sabemos onde começar (Lata 124) e que uma nota na Lata 124 nos diz que Lata contém o próximo item (Lata 432). ![{{{alt}}}](/files/eb8aec1e6e700ac4c10eba12a0557d9e49344506) Encontramos então uma terceira Lata, escrevemos o seu número (por exemplo, Lata 543) num pedaço de papel e colocamo-lo na *segunda* Lata (número 432). Depois colocamos o nosso terceiro item (círculo vermelho) na terceira Lata. Agora temos três Latas ligadas na sequência: o nosso ponto de partida, Lata 124 (círculo verde escuro) → Lata 432 (círculo verde claro) → Lata 543 (círculo vermelho) →… ![{{{alt}}}](/files/c6927c75ed901e7afd94224d15d31813fb041e0e) Repita este processo para os dois últimos itens (círculos azul claro e azul escuro) usando Lata 213 (círculo azul claro) e Lata 102 (círculo azul escuro). ![{{{alt}}}](/files/838676e4efd872f85031ba6aa8d4b32da171b2f6) Agora temos as 5 Latas todas ligadas entre si (usando o identificador numérico de cada Lata) e conseguimos recuperar todos os itens armazenados — na ordem correta — simplesmente visitando cada Lata por sua vez, removendo o nosso item e olhando para a nota que nos diz que Lata contém o nosso próximo item. ### E quanto ao último item da nossa lista (Lata 102)? Por que razão nos deveríamos preocupar especialmente com este? Até agora armazenámos cada item numa Lata, juntamente com uma nota a dizer que Lata contém o próximo item: para o último item da nossa lista, o que deveria dizer essa nota — visto que não há próxima Lata. Quando chegamos ao item final (Lata) tem de ser óbvio que esta Lata (que contém o último item) é o item final da nossa lista — não precisamos de procurar outra Lata, porque não existe nenhuma. Uma forma de o fazer é colocar um número de Lata “especial” dentro da nossa Lata final (102). Podemos usar qualquer número que quisermos, desde que escolhamos um número único que não seja o número de uma Lata real — por exemplo “Lata -1”, “Lata 0”: não importa, desde que saibamos que “Lata -1” ou “Lata 0” etc. nos dizem imediatamente para parar de procurar: não precisamos de procurar mais Latas porque esta é a última e, portanto, já não há mais itens para recuperar. ### De “itens” e “Latas” para tokens e TeX Agora precisamos de passar da nossa analogia para uma descrição mais próxima da realidade do TeX. Primeiro, em vez de armazenar círculos de cores diferentes nas nossas Latas imaginárias, deve ficar claro que poderíamos pensar nessas Latas como armazenando tokens TeX: inteiros simples. Essa é a parte mais fácil de transportar a nossa analogia para o domínio do software (TeX). Mas qual poderá ser o equivalente de software das nossas Latas físicas numeradas com “compartimentos”? Não queremos aventurar-nos demasiado em conceitos de programação, mas pode pensar nas nossas “Latas” como representando alguns bytes de memória do computador que foram “empacotados” numa unidade conveniente de armazenamento. O uso, na nossa analogia, de um identificador numérico para cada Lata pode ser considerado como a localização dentro da memória do computador onde cada pequeno pacote de memória está localizado. No próprio TeX, esses pequenos pacotes de armazenamento são chamados “palavras de memória” — um termo que reflete a época em que o TeX foi criado (década de 1970). Estas “palavras de memória” são o bloco de construção fundamental usado no TeX, mas não precisamos de as explorar aqui com mais detalhe — quem quiser mais pormenor pode consultar um artigo no [blog pessoal do autor](http://www.readytext.co.uk/?p=3537). Em termos de programação informática, o que estivemos a discutir chama-se [*lista ligada*](https://en.wikipedia.org/wiki/Linked_list): uma lista de tokens TeX é uma lista encadeada construída a partir dos recipientes de armazenamento do TeX chamados *palavras de memória* em que cada palavra de memória pode ser usada para armazenar: * a *valor*: o valor do token (um inteiro); * a *ligação*: a localização na memória da próxima palavra de memória que contém o próximo token da nossa lista. ## Onde é que o TeX usa listas de tokens? Em todo o lado! Isto é verdade porque uma definição de macro TeX/LaTeX (por exemplo, um comando LaTeX) é armazenada como uma forma (ligeiramente especializada) de lista de tokens — especializada no sentido de conter tokens que não vê em listas de tokens “standard” (relacionados com a correspondência de parâmetros da macro etc.). Não se preocupe com isso porque trataremos desses pormenores num artigo futuro. ### Um exemplo de macro Uma macro pode ser pensada como composta por três partes: ``` \def\{} ``` Note que, em vez de `\def` podia ter usado `\edef`, `\gdef` ou `\xdef`. **Nota para utilizadores de LaTeX**: Aqui estamos a definir macros usando comandos TeX brutos, de baixo nível (chamados *primitivos*). Os utilizadores de LaTeX estarão mais familiarizados com a criação de macros através da `\newcommand` (que é ela própria uma macro). Quando pede ao TeX para criar (definir) uma macro, ele cria um token que representa o `` uma *lista de tokens* que representa o combinado `` e ``. O TeX guardará cuidadosamente tudo para que o token que representa `` esteja ligado à lista de tokens que representa a sua definição (`` e ``). Por exemplo, se definirmos `\mymacro` assim: ```latex \def\mymacro abc #1 defz{I typed "#1"!} ``` Podemos ver que as suas partes constituintes são: * `` = `mymacro` * `` = `abc #1 defz` * `` = `Escrevi "#1"!` Por exemplo, podia chamar `\mymacro` assim: ```latex \mymacro abc THIS TEXT defz ``` o que resulta em `Escrevi "THIS TEXT"!` a ser formatado — o `abc` e `defz` estiver *contém* são formatados. `abc` e `defz` são sequências de tokens de carácter usadas para *delimitar* o parâmetro da macro `#1` e são absorvidas e descartadas quando a chamada da sua macro é processada com êxito pelo TeX. Quando definiu `\mymacro`, o padrão de tokens contido no armazenado atua como um “modelo” que o TeX pode usar para determinar: * quais os tokens na sua entrada que são os tokens delimitadores; * quais os tokens na sua entrada que realmente formam o(s) parâmetro(s) da sua macro (aqui, o que está a usar como `#1` na sua chamada de `\mymacro`). Tem de chamar `\mymacro` por um `` contendo delimitadores idênticos aos usados para a definir — isso inclui usar delimitadores de carácter com códigos de categoria idênticos. Se os delimitadores usados na `` usados para chamar `\mymacro` forem diferentes dos usados para a definir (o “modelo” armazenado na memória), então o TeX pode ficar bastante confuso — quando tenta processar `\mymacro` não seria capaz de corresponder ao “modelo” que guardou na sua memória. Quando o TeX vê que está a chamar uma macro, irá analisar o seu texto de entrada para criar novos tokens e tentar, token a token, correspondi-los com a lista de tokens `` modelo armazenado como parte da definição da sua macro. Se os delimitadores usados no seu texto de entrada resultarem numa série de tokens que não correspondem aos armazenados no “modelo”, então o TeX normalmente gerará um erro. O TeX é muito específico — lembre-se de que os tokens de carácter são uma combinação de código de carácter e código de categoria: se alterar o código de categoria de um carácter, obtém um valor de token diferente resultante desse carácter. Suponha que alterámos o código de categoria de `z` para, digamos, 12 — normalmente é 11 — e tentamos chamar a nossa macro assim: ```latex \catcode`z=12 \mymacro abc THIS TEXT defz more text here... ``` Desta vez não vai funcionar porque o código de categoria de `z` foi alterado. Vai ver um erro deste tipo: ```latex Argumento em fuga? THIS TEXT defz ! A parágrafo terminou antes de \mymacro estar completo. \par l.22 ``` Quando o TeX lê e analisa o `z` em `defz` não o consegue reconhecer como formando o fim de `\mymacro`’s `` usado no seu ficheiro de entrada. Até ver esse `z` errado, o TeX tinha correspondido corretamente aos primeiros 3 caracteres `def` mas esse `z` (com código de categoria 12) atrapalha a análise do TeX. Assumindo `z` tinha um código de categoria 11 quando nós *definimos* `\mymacro`: isso resultaria num valor de token de 256×11 + 122 = 2938 ser armazenado como parte da definição de `\mymacro`definição (isto é, armazenado como parte do “modelo”). No entanto, com o código de categoria 12, `z` irá agora criar um valor de token de 256×12 + 122 = 3194. Como o valor do token (de `z`) lido da sua entrada (valor 3194) não corresponde ao `z`-token contido no `` modelo da lista de tokens armazenado (valor 2938), o TeX continuará a analisar a sua entrada. O TeX continuará a analisar o texto que se segue após a sua macro (*mais texto aqui* ...) para procurar tokens adicionais — tentando corresponder o modelo armazenado com os tokens que encontra na sua entrada. Provavelmente não encontrará o padrão correto de tokens e irão surgir erros à medida que o TeX “ultrapassa” a sua entrada e lê erroneamente texto extra para criar tokens adicionais — esses tokens extra não deveriam ter sido lidos nesta fase e quase de certeza gerarão um erro. Vamos desenvolver isto em mais detalhe num artigo futuro. ## Outros usos de listas de tokens Outros comandos usados para criar/armazenar listas de tokens incluem: ```latex \toks={...} \everypar={...} \everymath={...} \everydisplay={...} \everyhbox={...} \everyvbox={...} \output={...} \everyjob={...} \everycr={...} \errhelp={...} ``` Cada um destes comandos cria uma lista de tokens a partir dos caracteres e comandos entre as chavetas ‘{...}’ e essa lista de tokens destina-se a ser reutilizada em determinadas circunstâncias. Por exemplo, `\everypar={...}` cria e armazena um conjunto de tokens (uma lista de tokens) que o TeX injeta na entrada imediatamente antes de iniciar um novo parágrafo. ## Usos ocultos de listas de tokens: exemplos Nesta secção final vamos analisar alguns exemplos práticos de listas de tokens a serem usadas de formas que talvez não espere. ### Exemplo 1: \uppercase{...} e \lowercase{....} — listas de tokens temporárias Além dos comandos explícitos para gerar listas de tokens, há circunstâncias em que o TeX gera uma lista de tokens interna oculta e temporária para fazer algum processamento especial. Lembre-se de que, quando o TeX lê/processa os seus caracteres/comandos de entrada, eles são convertidos em tokens: o bloco de construção fundamental com que os motores TeX trabalham. Um bom exemplo são os comandos `\uppercase{...}` ou `\lowercase{...}` porque o seu funcionamento pode, à primeira vista, ser bastante confuso. Uma vez que perceba o que estão a fazer — no interior mais profundo do TeX e invisível ao utilizador — o seu funcionamento torna-se muito mais fácil de compreender. Suponha que tem uma série simples de letras que quer pôr em maiúsculas — por exemplo, abcde — e convertê-la em ABCDE. Bem, é bastante simples com o `\uppercase` comando: ```latex \uppercase{abcde} ``` fará com que o TeX produza `ABCDE`. Agora suponhamos que queríamos guardar a nossa simples série de letras para usar mais tarde — isto é, não queremos produzi-las imediatamente, por isso vamos usar o único *interno* mecanismo do TeX — não o mecanismo externo (ficheiro) — para guardar dados: usar uma lista de tokens. Podemos fazer isso quer criando uma macro quer usando um comando explícito de lista de tokens: ```latex \toks100={abcde} \def\mychars{abcde} ``` Depois, em algum momento, pode decidir que gostaria de reutilizar a sua série de letras mas, desta vez, em maiúsculas; por isso tenta ```latex \uppercase{\the\toks100} ``` e ```latex \uppercase{\mychars} ``` Mas, infelizmente, nenhum destes funciona. Porquê? ### Listas de tokens secretas! Para compreender como os comandos `\uppercase{...}` `\lowercase{...}` funcionam realmente, precisei de espreitar o interior do funcionamento do TeX, pelo que a explicação seguinte deriva dessa análise. Quando o TeX deteta qualquer um de `\uppercase{}` ou `\lowercase{}` na sua entrada, a primeira coisa que o TeX faz é criar uma lista de tokens interna (temporária) a partir do `` encerrado entre ‘{’ e ‘}’ que se seguem depois dos `\uppercase{...}` ou `\lowercase{...}` comandos — essa lista de tokens temporária é interna ao TeX. Um ponto crucial, e central para compreender como `\uppercase{}` e `\lowercase{}` funcionam realmente, é que quaisquer comandos ou macros contidos no `` não são *expandido*: tudo o que o TeX faz é gerar tokens a partir de caracteres e comandos colocados entre `{...}`. Durante o funcionamento de `\uppercase{}` ou `\lowercase{}` nada entre as chavetas é executado: é simplesmente convertido em tokens. Depois do `` dentro do `{...}` foi convertido numa lista de tokens (temporária), o TeX volta então a visitar cada token dessa lista e testa se é um *carácter* token de carácter ou um *comando* token de comando (usando o valor numérico do token). Se o TeX deteta um token de carácter, modifica esse token para ajustar a maiúscula/minúscula do carácter (dependendo de `\uppercase` ou `\lowercase` estar a ser processado). O TeX simplesmente ignora quaisquer tokens de comando e não “olha para dentro” de quaisquer tokens de comando para ver o que representam ou contêm (por exemplo, uma macro contendo caracteres) — são simplesmente ignorados: apenas tokens de carácter são realmente processados/afetados pelas operações de alteração de maiúsculas/minúsculas. Por exemplo, se emitirmos um comando TeX como `\uppercase{abcde}` o TeX criará uma lista de tokens a partir de `abcde` contendo apenas tokens de carácter: todos eles são ajustados para criar uma série de tokens modificados representando A, B, C, D e E. Esses tokens modificados são reintroduzidos no processador de entrada do TeX, o que resulta em `ABCDE` ser formatado. No entanto, se tivermos armazenado os nossos caracteres *dentro de uma macro*—por exemplo `\def\mychars{abcde}`—e tentarmos convertê-los para maiúsculas assim: ```latex \uppercase{\mychars} ``` então isso irá falhar e abcde será formatado — não ABCDE como poderia esperar. Se depois tentarmos armazenar os nossos caracteres numa lista de tokens como `\toks0={abcde}` e fizermos `\uppercase{\the\toks0}` então, mais uma vez, `\uppercase` falhará porque a lista de tokens será composta inteiramente por tokens que não são afetados por `\uppercase`. Tomando o exemplo da nossa macro, `\mychars`, depois de o TeX detetar `\uppercase` na entrada, o TeX consulta o significado de `\uppercase` e executa-o, criando uma lista de tokens temporária a partir de `{\mychars}`. Claramente, essa lista de tokens temporária contém apenas um token que não é um token de carácter, mas sim um que representa o nosso comando de macro `\mychars`: portanto, para efeitos de execução de `\uppercase`, esse token é ignorado —`\mychars` não representa um token de carácter. No entanto, como observado acima, depois de `\uppercase` ter feito o seu trabalho, a lista de tokens temporária (criada pela ação de `\uppercase`) é reintroduzida no mecanismo completo de processamento de entrada (análise) do TeX. Quando o TeX volta a ler essa lista de tokens, deteta um token que representa a nossa `\mychars` macro, que o TeX executa (expande) e gera uma série de caracteres para formatar abcde — ainda em minúsculas porque estavam “embrulhados” dentro de uma macro e, portanto, invisíveis às ações de `\uppercase`. Uma vez que o TeX tenha reexaminado a lista de tokens temporária criada para `\uppercase{...}` ou `\lowercase{...}`, e processado quaisquer tokens de carácter, passa então a usar essa lista de tokens temporária como sua fonte de entrada: formatando caracteres (tokens de carácter processados) e executando comandos e macros. ### Como é que isto pode ser corrigido? Porque `\uppercase{...}` ou `\lowercase{...}` irá agir apenas sobre tokens de carácter, precisamos de uma forma de “forçar o desembalamento” dos caracteres contidos na nossa macro `\mychars` (ou contidos num `\toks` registo) antes de `\uppercase{...}` ou `\lowercase{...}` agir sobre ele. Por “desembalamento” o que realmente queremos dizer é o processo do TeX de *expansão*: * substituir um comando TeX/LaTeX pela *sequência* de tokens *a partir da qual esse comando* (*por exemplo, uma macro*) *é composto,* ou * produzindo a sequência de tokens que um comando foi concebido para *gerar*. Um exemplo de um comando que gera tokens é `\jobname`, que produz uma sequência de tokens de carácter que representam o nome do ficheiro principal TeX que está a ser processado. #### Magia de nível inferior: scantoks(..., ...) Aqui estamos realmente a sondar alguns cantos mais sombrios do funcionamento interno do TeX, por isso pode ignorar esta secção a menos que goste de detalhes… Depois de o TeX detetar `\uppercase` ou `\lowercase` no fluxo de entrada, executa uma função interna chamada `scantoks(..., ...)` cuja tarefa é gerar a lista de tokens usando os elementos entre a chaveta de abertura ‘{’ e a chaveta de fecho ‘}’ — como foi discutido, essa lista de tokens é subsequentemente examinada para detetar (e depois ajustar) quaisquer tokens de carácter para alterar a maiúscula/minúscula conforme necessário. Note com cuidado que estamos a referir-nos a `scantoks(..., ...)` como a função interna incorporada no código-fonte dos motores TeX — aqui, não estamos a referir-nos a ela como o nome de uma sequência de controlo. Como parte do seu trabalho, `scantoks(..., ...)` pode ser instruído sobre se deve expandir, ou não expandir, a lista de tokens que está a construir e para `\uppercase` e (`\lowercase`) não expande os tokens: simplesmente cria-os e coloca-os numa lista de tokens. Uma das primeiras coisas que `scantoks(..., ...)` tem de fazer é verificar se há uma chaveta de abertura ‘{’ (ou qualquer carácter de `\catcode` 1) porque tem de garantir que o utilizador não cometeu um erro de sintaxe e se esqueceu da chaveta de abertura ‘{’ (ou qualquer carácter com código de categoria 1) — porque é necessário um carácter com código de categoria 1 para delimitar o início de uma lista de itens a tokenizar. E aqui está o truque: a tarefa de procurar uma chaveta de abertura ‘{’ desencadeia `scantoks(..., ...)` a executar o processo de expansão do TeX, o que significa que os exemplos seguintes funcionarão: ```latex \let\ob={ \uppercase\ob abcde} \def\obb{\ob} \uppercase\obb xyz} ``` Tomando o exemplo de `\obb`, uma macro, ela é reconhecida como uma *comando expansível* sequência de controlo `scantoks(..., ...)` e é devidamente expandida pelo TeX (através da`\expandafter` função) na sua procura de uma chaveta de abertura (qualquer carácter com código de categoria 1). O que isto significa é que podemos usar o “ `\expandafter` truque” para alcançar o nosso objetivo de “desembalar” os nossos caracteres das limitações da nossa macro — ou seja, expandi-la. Note que *comando expansível*também se enquadra na categoria de uma Por isso, se definir: ```latex \toks0={abcde} \def\mychars{abcde} ``` E fizer isto: ```latex \uppercase\expandafter{\mychars} \uppercase\expandafter{\the\toks0} ``` em ambos os casos verá agora ABCDE ser formatado porque o `\expandafter` provoca o “desembalamento” (expansão) de `\mychars` e `\the\toks0`—ambos resultam em `\uppercase` ver um fluxo de tokens de carácter, que podem processar para alterar a maiúscula/minúscula. ### Exemplo 2: \string—mais listas de tokens temporárias Internamente, o TeX classifica `\string` como um dos seus chamados comandos “convert”: executando a operação de “converter para texto”. O `\string` O comando foi concebido para converter um token numa versão de texto legível por humanos — isto é, compor a cadeia de caracteres legível por humanos a partir da qual esse token foi originalmente criado. Por exemplo `\string\hello` cria uma lista temporária de tokens que contém os caracteres \\, h, e, l, l, o — sim, incluindo até o ‘\’ inicial. Assim que essa lista de tokens é criada, ela é então lida novamente pelo TeX e o texto do comando “`\hello`” é composto—sim, incluindo ‘\’ se escolher a fonte correta… Talvez se pergunte como/porquê o TeX consegue compor o caractere de escape quando normalmente ele é usado para fazer com que o analisador do TeX crie um token de comando: porque é que ele não faz isso aqui? A resposta tem a ver com códigos de categoria: normalmente, um caractere ‘\’ tem catcode 0 (caractere de escape), mas quando `\string` gera a sua lista interna de tokens, faz algo um pouco diferente. Quando cria uma lista de tokens de caracteres, atribui o código de categoria 12 a todos os caracteres, exceto ao caractere de espaço, ao qual é atribuído o catcode 10 — recorde-se de que os tokens de caracteres são calculados a partir de 256 x catcode + valor ASCII. Assim, quando o TeX volta a ler (a fazer input de) a lista temporária de tokens que `\string` foi gerada a partir de `\hello`, o TeX *não vê um caractere de escape* porque o token para ‘\’ foi calculado com catcode 12 e não 0: o TeX simplesmente trata ‘\’ como um caractere normal e compõe-o. Em rigor, talvez devamos notar que o TeX, na verdade, não gera um token para caracteres de escape quando os deteta na entrada. Assim que reconhece um caractere com código de categoria 0, esse caractere é apenas usado para “acionar” a geração de um token de sequência de controlo: depois de ter acionado o TeX para o fazer, o caractere de escape cumpriu a sua função e já não é considerado. ### Nota técnica Um comando chamado `\showtokens{...}` (introduzido pelo motor e-TeX) pode mostrar listas de tokens (no ficheiro de registo). Do manual do e-TeX: > O comando `\showtokens{}` mostra a lista de tokens e permite a exibição de quantidades que não podem ser exibidas por `\show` ou `\showthe`, por exemplo: > > ```latex > \showtokens\expandafter{\jobname} > ``` ## Em conclusão Na secção 291 do código-fonte do TeX (ver página 122 de [TeX: The Program](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373)) Knuth descreve uma lista de tokens da seguinte forma: > “Uma lista de tokens é uma lista ligada simples de nós de uma palavra em mem, em que cada palavra contém um token e uma ligação. As definições de macros, definições da rotina de saída, marcas, `\write` textos e algumas outras coisas são guardados pelo TeX na forma de listas de tokens, normalmente precedidas por um nó com uma contagem de referências no seu campo “token\_ref\_count”.” Na primeira leitura, isto pode não ter sido fácil de entender, mas, com sorte, agora talvez faça um pouco mais de sentido. --- # 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/overleaf-learn-latex-pt/artigos-aprofundados/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.