> 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/es/articulos-en-profundidad/54-what-is-a-tex-token-list.md). # Qué es una lista de tokens de TeX ## Entonces, ¿qué es exactamente una "lista de tokens de TeX"? En un [artículo anterior](/latex/es/articulos-en-profundidad/53-what-is-a-tex-token.md)—también parte de esta [serie sobre las teccnicidades de bajo nivel de TeX](/latex/es/articulos-en-profundidad/01-a-new-series-of-articles-tex-tokens-and-related-concepts-but-why-and-how.md)—exploramos los procesos mediante los cuales TeX escanea tu `.tex` archivo para generar nuevos tokens: examinamos la naturaleza fundamental de un token de TeX y cómo TeX los crea (véase [¿Qué es un "token de TeX"?](/latex/es/articulos-en-profundidad/53-what-is-a-tex-token.md)). En este artículo de seguimiento echamos un vistazo a *lista de tokens*s: qué son y cómo los motores de TeX los crean/utilizan. Entender las listas de tokens puede ser complicado porque se almacenan en lo más profundo de los internos de TeX: esos detalles quedan ocultos al usuario—aunque, hoy en día, esto no siempre es así si haces programación más avanzada con LuaTeX. Pero, por ahora, puedes empezar a pensar en las listas de tokens como la forma en que TeX almacena una serie de valores enteros, donde cada entero es un token derivado de un carácter o comando que TeX ha leído de tu archivo de entrada. Las listas de tokens desempeñan un papel fundamental en el funcionamiento interno de TeX, a menudo de maneras sorprendentes, como en el funcionamiento interno de comandos como `\uppercase` y `\lowercase`. Un uso especialmente importante de las listas de tokens es almacenar y ejecutar macros, un tema que examinaremos en detalle como parte de un futuro artículo de esta serie. ### TeX obtiene su entrada de archivos y listas de tokens Los motores de TeX tienen tres fuentes de entrada—dos que quizá conozcas: * archivos de texto físicos almacenados en el disco; * texto que un usuario escribe en el terminal (línea de comandos); ¡pero también tiene una tercera forma de leer/obtener entrada: listas de tokens! Las listas de tokens son, en efecto, una instalación interna de almacenamiento de datos que TeX utiliza como parte de sus operaciones. Debido a que las listas de tokens de TeX actúan como una "instalación de almacenamiento" para tokens creados previamente, tiene sentido que TeX pueda reutilizarlas como otra fuente de entrada. Cuando se vuelve necesario tomar su siguiente entrada de una lista de tokens particular (o se le indica a TeX que lo haga), TeX detendrá temporalmente la lectura de entrada desde un archivo físico (es decir, la creación de *nuevos tokens*) y cambiará a obtener su entrada desde *tokens existentes*: la ubicación en memoria donde se almacena la lista de tokens. Evidentemente, con una lista de tokens el proceso de escaneo + generación de tokens ya ha tenido lugar, así que TeX solo necesita mirar cada token de la lista y decidir qué hacer con cada uno. Como ejemplo rápido, el comando (primitivo de TeX) de bajo nivel `\toks` te permite crear una lista de tokens que TeX guarda en memoria para su reutilización posterior: ```latex \toks100={Hello} ``` Para recuperar esos tokens (es decir, decirle a TeX que los trate como su siguiente fuente de entrada) emitirías un comando como ```latex \the\toks100 ``` Esto hará que TeX cambie de crear nuevos tokens a partir de tu archivo de entrada a obtener el siguiente desde donde esos tokens (creados por `\toks`) están almacenados—en un llamado *registro de tokens* que no es más que una ubicación interna de memoria conocida por TeX (aquí es el registro 100). Además, las listas de tokens pueden generarse internamente, sobre la marcha, mediante varios comandos de TeX. Un ejemplo es el comando `\jobname` que genera una serie de tokens de caracteres—un token por cada carácter en el nombre del archivo principal que TeX está procesando. Otro ejemplo es el comando `\string` ; por ejemplo ```latex \string\mymacro ``` genera una serie de tokens de caracteres para cada letra del nombre `\mymacro`—incluido el `\` carácter inicial. Echamos un vistazo más de cerca a algunos "comandos generadores de tokens" al final de este artículo. ## Lista de tokens: explicada por analogía A menos que tengas experiencia en programación y/o algunos conocimientos de informática, las "listas de tokens" pueden ser un concepto algo difuso y, quizá, un poco confuso. Sin embargo, si deseas llegar a dominar la escritura de macros de TeX/LaTeX, entonces un buen entendimiento de temas como los tokens de TeX, las listas de tokens y los códigos de categoría (`\catcode`) resultará extremadamente útil. En esta sección vamos a usar una analogía para explicar/ilustrar las ideas/principios fundamentales de una lista de tokens de TeX: cómo TeX almacena tokens en memoria. Vale la pena dedicar tiempo a leer esto porque las listas de tokens son un aspecto *fundamental* de TeX y merece la pena entenderlo con un poco más de detalle. ### Listas de tokens: una analogía (experimento mental) Vamos a trabajar mediante un "experimento mental" para ofrecer una base para entender las listas de tokens de TeX. Imagina que tuvieras acceso a un gran conjunto de contenedores, como cientos de latas—no podemos considerar ni usar el término "caja" para describir los contenedores de nuestro experimento mental porque, por supuesto, "caja" tiene un significado muy específico en TeX, totalmente ajeno a nuestra discusión aquí. Así que llamaremos a nuestros contenedores "latas", donde cada lata: * tiene un número identificador único impreso en el exterior; * está dividida (internamente) en dos compartimentos. Esos dos compartimentos están diseñados de la siguiente manera: * el compartimento de la izquierda contiene el elemento que quieres poner en la lata; * el compartimento de la derecha está diseñado para contener un trozo de papel en el que puedes escribir un único número: el número que identifica a otra lata. ![prueba](/files/8c63de1e56aca369c885af0c323b02fdf3badf7e) Supón que tienes una colección de, digamos, 5 elementos y quieres almacenar esa colección de elementos dentro de esas latas; pero, por desgracia, cada lata solo puede contener 1 elemento del tipo que quieres almacenar. Para simplificar, supongamos que queremos almacenar 5 círculos de colores: ![{{{alt}}}](/files/123f54cf3adbc48a0ac303984e70f1b8e7a93e74) Además, cuando vuelvas para recuperar esos elementos de tu sistema de almacenamiento (latas), esos elementos *debe* deben recuperarse/encontrarse en un orden determinado: el orden en que fueron almacenados; esa secuencia debe preservarse. ¿Cómo puedes lograrlo? Podemos aprovechar el hecho de que cada lata: * tiene un número identificador único adherido en el exterior; * tiene 2 compartimentos—solo 1 de los cuales utilizaremos para contener nuestro elemento, el otro contiene un trozo de papel con el número de otra lata escrito en él. Supondremos que cada lata está vacía—pero nada te impide abrir cualquier lata concreta para comprobar si está vacía; si no lo está, prueba con la siguiente hasta encontrar una lata vacía. Lo que podríamos hacer es lo siguiente. Poner nuestro primer elemento (círculo verde oscuro) en una de nuestras latas (por ejemplo, la lata 124) y anotar el número de esta primera lata—no importa qué número tenga esa primera lata, lo único que importa es que lo escribamos en algún lugar y lo guardemos para usarlo más adelante. ![{{{alt}}}](/files/6d2bd3eac50a8fe09bbb4b8d1c2eca1d8ad26645) Busca una segunda lata—cualquier número de lata (por ejemplo, la lata 432)—y toma nota de su número. Escribe el número de esa segunda lata (432) en un trozo de papel y coloca esa nota *dentro de la primera lata* (lata 124). Colocamos nuestro segundo elemento (círculo verde claro) en la segunda lata. Así que, actualmente, tenemos la siguiente situación: * una nota escrita—no almacenada en una lata—que indica que la primera lata es la número 124 (contiene nuestro primer elemento); * dentro de la lata 124 hemos añadido otra nota que dice que el siguiente elemento debe encontrarse en la lata 432. En esencia, hemos *enlazado* nuestras dos primeras latas: sabemos dónde empezar (lata 124) y que una nota en la lata 124 nos indica qué lata contiene el siguiente elemento (lata 432). ![{{{alt}}}](/files/5ff4f361bb6defde1a94538826d123be02a0415c) Luego encontramos una tercera lata, escribimos su número (por ejemplo, lata 543) en un trozo de papel y lo colocamos en la *segunda* lata (número 432). Luego colocamos nuestro tercer elemento (círculo rojo) en la tercera lata. Ahora hemos enlazado tres latas en la secuencia: nuestro punto de partida, lata 124 (círculo verde oscuro) → lata 432 (círculo verde claro)→ lata 543 (círculo rojo) →… ![{{{alt}}}](/files/ec8ba2cbed8db310f76316b12ac225981fdf1831) Repite este proceso para los dos últimos elementos (círculos azul claro y azul oscuro) usando la lata 213 (círculo azul claro) y la lata 102 (círculo azul oscuro). ![{{{alt}}}](/files/86f5579f7a7e95841be25152657fe7646536f1f8) Ahora tenemos las 5 latas enlazadas entre sí (usando el identificador numérico de cada lata) y somos capaces de recuperar todos nuestros elementos almacenados—en el orden correcto—simplemente visitando cada lata por turno, retirando nuestro elemento y mirando la nota que nos dice qué lata contiene nuestro siguiente elemento. ### ¿Qué pasa con el último elemento de nuestra lista (lata 102)? ¿Por qué deberíamos preocuparnos por este en particular? Hasta ahora hemos almacenado cada elemento en una lata, junto con una nota que dice qué lata contiene el siguiente elemento: para el último elemento de nuestra lista, ¿qué debería decir esa nota—si no hay ninguna lata siguiente? Cuando llegamos al elemento final (lata) tiene que ser obvio que esta lata (que contiene el último elemento) es el último elemento de nuestra lista—no necesitamos buscar otra lata, porque no existe ninguna. Una forma de hacerlo es usar colocar un número de lata "especial" dentro de nuestra lata final (102). Podemos usar cualquier número que queramos siempre que elijamos un número único que no sea el número de una lata real—por ejemplo "lata -1", "lata 0": no importa siempre que sepamos que "lata -1" o "lata 0" etc. nos indica inmediatamente que debemos dejar de buscar: no necesitamos buscar más latas porque esta es la última y, por tanto, no hay más elementos que recuperar. ### De "elementos" y "latas" a tokens y TeX Ahora necesitamos pasar de nuestra analogía a una descripción más cercana a la realidad de TeX. En primer lugar, en lugar de almacenar círculos de distintos colores en nuestras latas imaginarias, debería quedar claro que podríamos pensar en esas latas como almacenamiento de tokens de TeX: simples enteros. Esa es la parte más fácil de trasladar nuestra analogía al ámbito del software (TeX). Pero, ¿cuál podría ser el equivalente de software de nuestras latas físicas numeradas con "compartimentos"? No queremos aventurarnos demasiado en conceptos de programación, pero puedes pensar en nuestras "latas" como la representación de unos pocos bytes de memoria del ordenador que han sido "empaquetados" en una unidad de almacenamiento conveniente. El uso de un identificador numérico para cada lata en nuestra analogía puede considerarse como la ubicación dentro de la memoria del ordenador donde se encuentra cada pequeño paquete de memoria. Dentro del propio TeX, esos pequeños paquetes de almacenamiento se llaman "palabras de memoria"—un término que refleja la época en que se creó TeX (la década de 1970). Estas "palabras de memoria" son el bloque de construcción fundamental que se usa dentro de TeX, pero no necesitamos explorarlas con más detalle aquí—quien desee más información puede consultar un artículo en [el blog personal del autor](http://www.readytext.co.uk/?p=3537). En términos de programación informática, lo que hemos estado discutiendo se llama una [*lista enlazada*](https://en.wikipedia.org/wiki/Linked_list): una lista de tokens de TeX es una lista enlazada construida a partir de los contenedores de almacenamiento de TeX llamados *palabras de memoria* donde cada palabra de memoria puede utilizarse para almacenar: * a *valor*: el valor del token (un entero); * a *enlace*: la ubicación en memoria de la siguiente palabra de memoria que contiene el siguiente token de nuestra lista. ## ¿Dónde usa TeX listas de tokens? ¡En todas partes! Esto es cierto porque una definición de macro de TeX/LaTeX (por ejemplo, un comando de LaTeX) se almacena como una forma (algo especializada) de lista de tokens—especializada en el sentido de que contiene tokens que no ves en las listas de tokens "estándar" (relacionados con la coincidencia de parámetros de macro, etc.). No te preocupes por esto porque abordaremos esos detalles en un artículo futuro. ### Un ejemplo de macro Una macro puede considerarse compuesta por tres partes: ``` \def\{} ``` Ten en cuenta que en lugar de `\def` podrías haber usado `\edef`, `\gdef` o `\xdef`. **Nota para los usuarios de LaTeX**: Aquí estamos definiendo macros usando comandos de TeX en bruto, de bajo nivel (llamados *primitivas*). Los usuarios de LaTeX estarán más familiarizados con la creación de macros mediante `\newcommand` de LaTeX (que en sí mismo es una macro). Cuando le pides a TeX que cree (defina) una macro, creará un token que representa el `` y una *lista de tokens* que representa el combinado `` y ``. TeX almacenará cuidadosamente todo para que el token que representa `` esté enlazado con la lista de tokens que representa su definición (`` y ``). Por ejemplo, si definimos `\mymacro` así: ```latex \def\mymacro abc #1 defz{¡Escribí "#1"!} ``` Podemos ver que sus partes constituyentes son: * `` = `mymacro` * `` = `abc #1 defz` * `` = `¡Escribí "#1"!` Por ejemplo, podrías invocar `\mymacro` así: ```latex \mymacro abc ESTE TEXTO defz ``` lo que da como resultado `¡Escribí "ESTE TEXTO"!` se componga— `abc` y `defz` estás *contiene* componga. `abc` y `defz` son secuencias de tokens de caracteres usados para *delimitar* el parámetro de la macro `#1` y son absorbidos y descartados cuando TeX procesa correctamente la llamada a tu macro. Cuando definiste `\mymacro`, el patrón de tokens contenido en lo almacenado actúa como una "plantilla" que TeX puede usar para determinar: * qué tokens de tu entrada son los tokens delimitadores; * qué tokens de tu entrada forman realmente el/los parámetro(s) de tu macro (aquí, lo que estás usando como `#1` en tu llamada de `\mymacro`). Tienes que llamar a `\mymacro` por un `` conteniendo delimitadores idénticos a los usados para definirla—eso incluye usar delimitadores de caracteres con códigos de categoría idénticos. Si los delimitadores usados en `` para llamar a `\mymacro` son distintos de los usados para definirla (la "plantilla" almacenada en memoria), entonces TeX puede quedar bastante confundido—cuando intenta procesar `\mymacro` no sería capaz de hacer coincidir la "plantilla" que ha guardado en su memoria. Cuando TeX ve que estás llamando a una macro, escaneará tu texto de entrada para crear nuevos tokens e intentará, token por token, hacerlos coincidir con la lista de tokens `` plantilla almacenada como parte de la definición de tu macro. Si los delimitadores usados en tu texto de entrada dan como resultado una serie de tokens que no coinciden con los almacenados en la "plantilla", entonces TeX normalmente mostrará un error. TeX es muy particular—recuerda que los tokens de caracteres son una combinación de código de carácter y código de categoría: si cambias el código de categoría de un carácter obtienes un valor de token diferente a partir de ese carácter. Supongamos que cambiamos el código de categoría de `z` a, digamos, 12—normalmente es 11—e intentamos llamar a nuestra macro así: ```latex \catcode`z=12 \mymacro abc ESTE TEXTO defz más texto aquí... ``` Esta vez no funcionará porque el código de categoría de `z` ha cambiado. Verás un error como este: ```latex ¿Argumento desbocado? ESTE TEXTO defz ! El párrafo terminó antes de que \mymacro estuviera completo. \par l.22 ``` Cuando TeX lee y escanea el `z` % en `defz` no puede reconocerlo como el final de `\mymacro`de `` usado en tu archivo de entrada. Hasta ver ese `z` erróneo, TeX había coincidido correctamente con los primeros 3 caracteres `def` pero eso `z` (con código de categoría 12) hace tropezar el escaneo de TeX. Suponiendo que `z` tuviera un código de categoría 11 cuando *definimos* `\mymacro`: eso daría como resultado que se almacenara un valor de token de 256×11 + 122 = 2938 como parte de la definición de `\mymacro`(es decir, almacenado como parte de la "plantilla"). Sin embargo, con código de categoría 12, `z` ahora creará un valor de token de 256×12 + 122 = 3194. Debido a que el valor del token (para `z`) leído de tu entrada (valor 3194) no coincide con el token `z`contenido en la plantilla de lista de tokens almacenada (valor 2938), TeX seguirá escaneando tu entrada. TeX continuará escaneando el texto que sigue después de tu macro ( `` más texto aquí*)... para buscar tokens adicionales—tratando de hacer coincidir la plantilla almacenada con los tokens que encuentra en tu entrada. Probablemente no encontrará el patrón correcto de tokens y se producirán errores cuando TeX "se pase" de tu entrada y lea erróneamente texto extra para crear tokens adicionales—esos tokens extra no deberían haberse leído en este punto y casi con seguridad generarán un error.* Lo veremos con más detalle en un artículo futuro. Otros usos de las listas de tokens ## Otros comandos utilizados para crear/almacenar listas de tokens incluyen: \toks\={...} ```latex \toks={...} \everypar={...} \everymath={...} \everydisplay={...} \everyhbox={...} \everyvbox={...} \output={...} \everyjob={...} \everycr={...} \errhelp={...} ``` Cada uno de estos comandos crea una lista de tokens a partir de los caracteres y comandos dentro de las llaves ‘{...}’ y esa lista de tokens está destinada a reutilizarse en ciertas circunstancias. Por ejemplo, `\everypar={...}` crea y almacena un conjunto de tokens (una lista de tokens) que TeX inyecta en la entrada justo antes de empezar un nuevo párrafo. ## Usos ocultos de las listas de tokens: ejemplos En esta sección final veremos algunos ejemplos prácticos de listas de tokens usadas de maneras que quizá no esperarías. ### Ejemplo 1: \uppercase{...} y \lowercase{....}—listas de tokens temporales Además de los comandos explícitos para generar listas de tokens, hay circunstancias en las que TeX genera una lista de tokens interna oculta y temporal para hacer algún procesamiento especial. Recuerda que cuando TeX lee/procesa tus caracteres/comandos de entrada, estos se convierten en tokens: el bloque de construcción fundamental con el que trabajan los motores de TeX. Un buen ejemplo son los comandos `\uppercase{...}` o `\lowercase{...}` porque su funcionamiento puede, a primera vista, resultar bastante confuso. Una vez que entiendes lo que están haciendo—más profundamente dentro de TeX e invisible para el usuario—su funcionamiento se vuelve mucho más fácil de comprender. Supón que tienes una simple serie de letras que quieres poner en mayúsculas—por ejemplo, abcde y convertirla en ABCDE. Bueno, es bastante sencillo con el comando de TeX `\uppercase` comando: ```latex \uppercase{abcde} ``` hará que TeX produzca `ABCDE`. Ahora supongamos que quisiéramos guardar nuestra simple serie de letras para usarla más tarde—es decir, no queremos sacarlas directamente, así que usaremos el único mecanismo *interno* de TeX—no el mecanismo externo (de archivo)—para guardar datos: usar una lista de tokens. Podemos hacerlo ya sea creando una macro o usando un comando explícito de lista de tokens: ```latex \toks100={abcde} \def\mychars{abcde} ``` Entonces, en algún momento, podrías decidir que te gustaría reutilizar tu serie de letras pero, esta vez, en mayúsculas; así que intentas ```latex \uppercase{\the\toks100} ``` y ```latex \uppercase{\mychars} ``` Pero, por desgracia, ninguno de estos funciona. ¿Por qué? ### ¡Listas de tokens secretas! Para entender cómo funcionan realmente los comandos `\uppercase{...}` `\lowercase{...}` tuve que echar un vistazo al funcionamiento interno de TeX, así que la siguiente explicación se deriva de haber hecho eso. Cuando TeX detecta cualquiera de `\uppercase{}` o `\lowercase{}` en tu entrada, lo primero que hace TeX es crear una lista de tokens interna (temporal) a partir de `` encerrado entre las ‘{’ y ‘}’ que siguen después de los `\uppercase{...}` o `\lowercase{...}` comandos—esa lista de tokens temporal es interna a TeX. Un punto crucial, y central para entender cómo `\uppercase{}` y `\lowercase{}` funcionan realmente, es que cualquier comando o macro contenido en los `` no se *expandido*ejecuta: todo lo que hace TeX es generar tokens a partir de caracteres y comandos colocados entre `{...}`. Durante la operación de `\uppercase{}` o `\lowercase{}` nada de lo que está entre las llaves se ejecuta: simplemente se convierte en tokens. Después de `` dentro del `{...}` se ha convertido en una lista de tokens (temporal), TeX vuelve a examinar cada token de esa lista y comprueba si es un *carácter* token de carácter o un *comando* token de comando `\uppercase` o `\lowercase` (usando el valor numérico del token). Si TeX detecta un token de carácter, modifica ese token para ajustar el caso del carácter (según si se está procesando). TeX simplemente ignora cualquier token de comando y no "mira dentro" de los tokens de comando para ver qué representan o contienen (por ejemplo, una macro que contiene caracteres)—simplemente los salta: solo los tokens de carácter son realmente procesados/afectados por las operaciones de cambio de mayúsculas/minúsculas. `\uppercase{abcde}` TeX creará una lista de tokens a partir de `abcde` que no contiene nada más que tokens de carácter: todos se ajustan para crear una serie de tokens modificados que representan A, B, C, D y E. Esos tokens modificados se devuelven al procesador de entrada de TeX, lo que da como resultado `ABCDE` se componga. Sin embargo, si hemos almacenado nuestros caracteres *dentro de una macro*—por ejemplo `\def\mychars{abcde}`—e intentamos convertirlos a mayúsculas así: ```latex \uppercase{\mychars} ``` entonces fallará y se compondrá abcde—no ABCDE como cabría esperar. Si luego intentamos almacenar nuestros caracteres en una lista de tokens como `\toks0={abcde}` y hacemos `\uppercase{\the\toks0}` entonces, una vez más, `\uppercase` fallará porque la lista de tokens estará compuesta completamente por tokens que no se ven afectados por `\uppercase`. Tomando el ejemplo de nuestra macro, `\mychars`, después de que TeX detecta `\uppercase` en la entrada, TeX busca el significado de `\uppercase` y lo acciona, creando una lista de tokens temporal a partir de `{\mychars}`. Claramente, esa lista de tokens temporal contiene solo un token que no es un token de carácter, sino uno que representa nuestro comando de macro `\mychars`: por lo tanto, para los propósitos de ejecutar `\uppercase`, ese token se ignora—`\mychars` no representa un token de carácter. Sin embargo, como se señaló arriba, una vez que `\uppercase` ha hecho su trabajo, la lista de tokens temporal (creada por la acción de `\uppercase`) se devuelve al mecanismo completo de procesamiento de entrada (escaneo) de TeX. Cuando TeX vuelve a leer esa lista de tokens detecta un token que representa nuestra `\mychars` macro que TeX ejecuta (expande) y genera una serie de caracteres para componer abcde—todavía en minúsculas porque estaban "envueltos" dentro de una macro y, por tanto, invisibles a las acciones de `\uppercase`. Una vez que TeX ha vuelto a examinar la lista de tokens temporal creada para `\uppercase{...}` o `\lowercase{...}`, y ha procesado cualquier token de carácter, entonces cambia a usar esa lista de tokens temporal como su fuente de entrada: componiendo caracteres (tokens de carácter procesados) y ejecutando comandos y macros. ### ¿Cómo se puede arreglar esto? Porque `\uppercase{...}` o `\lowercase{...}` solo actuará sobre tokens de carácter, necesitamos una forma de "forzar el desembalaje" de los caracteres contenidos en nuestra macro `\mychars` (o contenidos en un `\toks` registro) antes de que `\uppercase{...}` o `\lowercase{...}` actúe sobre ello. Por "desembalaje" lo que realmente queremos decir es el proceso de TeX de *macro*: * reemplazar un comando de TeX/LaTeX con la *secuencia* de tokens *de la que ese comando* (*por ejemplo, una macro*) *está compuesto,* o * produciendo la secuencia de tokens que un comando está diseñado para *generar*. Un ejemplo de un comando que genera tokens es `\jobname`, que produce una secuencia de tokens de caracteres que representan el nombre del archivo principal de TeX que se está procesando. #### Magia de nivel más bajo: scantoks(..., ...) Aquí estamos realmente investigando algunos rincones más oscuros del funcionamiento interno de TeX, así que puedes ignorar esta sección a menos que disfrutes de los detalles… Después de que TeX detecta `\uppercase` o `\lowercase` en el flujo de entrada, ejecuta una función interna llamada `scantoks(..., ...)` cuya tarea es generar la lista de tokens usando los elementos entre la ‘{’ de apertura y la ‘}’ de cierre—como se ha explicado, esa lista de tokens se examina posteriormente para detectar (y luego ajustar) cualquier token de carácter para alterar el caso del carácter según sea necesario. Observa cuidadosamente que nos estamos refiriendo a `scantoks(..., ...)` como la función interna integrada en el código fuente de los motores de TeX—aquí no se está aludiendo al nombre de una secuencia de control. Como parte de su trabajo, `scantoks(..., ...)` puede indicarse si debe expandir, o no expandir, la lista de tokens que está construyendo y para `\uppercase` y (`\lowercase`) no expande los tokens: simplemente los crea y los coloca en una lista de tokens. Una de las primeras cosas que `scantoks(..., ...)` tiene que hacer es comprobar si hay una ‘{’ de apertura (o cualquier carácter con `\catcode` 1) porque debe asegurarse de que el usuario no haya cometido un error de sintaxis y haya olvidado la ‘{’ de apertura (o cualquier carácter con código de categoría 1)—porque se requiere un carácter con código de categoría 1 para delimitar el comienzo de una lista de elementos que serán tokenizados. Y aquí está el truco: la tarea de buscar una ‘{’ de apertura desencadena `scantoks(..., ...)` para ejecutar el proceso de expansión de TeX, lo que significa que los siguientes ejemplos funcionarán: ```latex \let\ob={ \uppercase\ob abcde} \def\obb{\ob} \uppercase\obb xyz} ``` Tomando el ejemplo de `\obb`, una macro, se reconoce como un *comando expandible* y TeX lo expande debidamente (mediante la `scantoks(..., ...)` función) en su búsqueda de una llave de apertura (cualquier carácter con código de categoría 1). Lo que esto significa es que podemos usar el "`\expandafter` truco" para lograr nuestro objetivo de "desempaquetar" nuestros caracteres desde los confines de nuestra macro—es decir, expandirla. Observa que `\expandafter` también entra en la categoría de ser un *comando expandible*, así que TeX lo acciona aquí y deja que haga su trabajo como parte de la búsqueda de una ‘{’ de apertura (o cualquier carácter con código de categoría 1). Entonces, si defines: ```latex \toks0={abcde} \def\mychars{abcde} ``` Y haces esto: ```latex \uppercase\expandafter{\mychars} \uppercase\expandafter{\the\toks0} ``` en ambos casos verás ahora ABCDE compuesto porque el `\expandafter` provoca el "desembalaje" (expansión) de `\mychars` y `\the\toks0`—ambos dan como resultado `\uppercase` ver un flujo de tokens de carácter, que pueden procesar para cambiar el caso. ### Ejemplo 2: \string—más listas de tokens temporales Internamente, TeX clasifica `\string` como uno de sus llamados comandos de "conversión": realizar la operación de "convertir a texto". El `\string` El comando está diseñado para convertir un token en una versión de texto legible por humanos; es decir, componer tipográficamente la cadena legible por humanos de caracteres a partir de la cual se creó originalmente ese token. Por ejemplo `\string\hello` crea una lista temporal de tokens que contiene los caracteres \\, h, e, l, l, o — sí, incluso incluyendo la ‘\’ inicial. Una vez que esa lista de tokens ha sido creada, TeX la vuelve a leer y el texto del comando “`\hello`” se compone tipográficamente—sí, incluyendo ‘\’ si eliges la fuente correcta… Quizá te preguntes cómo/por qué TeX puede componer tipográficamente el carácter de escape cuando normalmente se usa para hacer que el escáner de TeX cree un token de comando: ¿por qué no hace eso aquí? La respuesta tiene que ver con los códigos de categoría: normalmente, un carácter ‘\’ tiene catcode 0 (carácter de escape), pero cuando `\string` genera su lista interna de tokens hace algo un poco diferente. Cuando crea una lista de tokens de caracteres, asigna el código de categoría 12 a todos los caracteres, aparte del carácter espacio, al que se le asigna catcode 10; recuerda que los tokens de caracteres se calculan como 256 x catcode + valor ASCII. Así que, cuando TeX vuelve a leer (input) la lista temporal de tokens que `\string` se generó a partir de `\hello`, TeX *no ve un carácter de escape* porque el token para ‘\’ se calculó con un catcode 12 y no 0: TeX simplemente trata ‘\’ como un carácter normal y lo compone tipográficamente. En sentido estricto, probablemente deberíamos señalar que TeX en realidad no genera un token para los caracteres de escape cuando los detecta en la entrada. Una vez que ha reconocido un carácter con código de categoría 0, ese carácter simplemente se usa para “desencadenar” la generación de un token de secuencia de control: una vez que ha hecho que TeX haga eso, el carácter de escape ha cumplido su función y ya no se tiene en cuenta. ### Nota técnica Un comando llamado `\showtokens{...}` (introducido por el motor e-TeX) puede mostrar listas de tokens (en el archivo de registro). Del manual de e-TeX: > El comando `\showtokens{}` muestra la lista de tokens, y permite mostrar cantidades que no pueden mostrarse con `\show` o `\showthe`, por ejemplo: > > ```latex > \showtokens\expandafter{\jobname} > ``` ## En conclusión En la sección 291 del código fuente de TeX (véase la página 122 de [TeX: El programa](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373)) Knuth describe una lista de tokens de la siguiente manera: > “Una lista de tokens es una lista simplemente enlazada de nodos de una palabra en mem, donde cada palabra contiene un token y un enlace. Las definiciones de macros, las definiciones de la rutina de salida, las marcas, `\write` los textos, y algunas otras cosas son recordadas por TeX en forma de listas de tokens, normalmente precedidas por un nodo con un contador de referencias en su campo “token\_ref\_count”.” A primera lectura quizá no haya sido fácil de entender, pero, con suerte, ahora puede tener un poco más 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/es/articulos-en-profundidad/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.