> 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/21-how-does-expandafter-work-tex-uses-temporary-token-lists.md).

# Cómo funciona \expandafter: TeX usa listas temporales de tokens

[Parte 1](/latex/es/articulos-en-profundidad/19-how-does-expandafter-work-an-introduction-to-tex-tokens.md) [Parte 2](/latex/es/articulos-en-profundidad/22-how-does-expandafter-work-the-meaning-of-expansion.md) [Parte 3](/latex/es/articulos-en-profundidad/21-how-does-expandafter-work-tex-uses-temporary-token-lists.md) [Parte 4](/latex/es/articulos-en-profundidad/20-how-does-expandafter-work-from-basic-principles-to-exploring-tex-s-source-code.md) [Parte 5](/latex/es/articulos-en-profundidad/17-how-does-expandafter-work-a-detailed-macro-case-study.md) [Parte 6](/latex/es/articulos-en-profundidad/18-how-does-expandafter-work-a-detailed-study-of-consecutive-expandafter-commands.md)

## Expansión y listas internas de tokens

Hasta ahora hemos explorado los tokens, las listas de tokens y los principios básicos detrás del concepto de expansión de TeX. En esta sección usaremos la primitiva de TeX `\\jobname` para introducir un aspecto importante del procesamiento de la expansión: el uso que hace TeX de *listas temporales de tokens*—que son un *fundamental* aspecto de cómo `\\expandafter` funciona, como veremos más adelante en esta serie de artículos.

`\\jobname` es una primitiva expandible de TeX cuya expansión genera una serie de tokens de caracteres que representan el nombre del archivo de entrada principal `.tex` archivo. Por ejemplo, supongamos que tuviéramos el siguiente texto como parte de un `.tex` archivo llamado `mycode.tex`:

```
    El nombre de mi archivo es \jobname .tex %Observa el espacio después de \jobname
```

Esto se compondría

```
    El nombre de mi archivo es mycode.tex
```

Cuando usamos el `\\jobname` comando, los caracteres compuestos resultantes no se leen de tu `.tex` archivo físico, entonces ¿de dónde provienen?: ¿dónde almacena/lee TeX esos tokens? Invisible para el usuario (es decir, en lo más profundo de TeX mismo), el proceso de expansión de `\\jobname` crea una lista temporal de tokens construida a partir de la serie de tokens de caracteres que representan el nombre de tu archivo. Una vez `\\jobname` ha creado esa lista de tokens, TeX temporalmente “desvía su mirada” de su fuente de entrada actual (aquí, nuestro `.tex` archivo) para leer tokens (tokens de caracteres) de esa lista temporal de tokens. Cuando TeX necesita otro token de entrada, leerá su siguiente token de esa lista interna y seguirá haciéndolo hasta llegar al final de la lista; en ese punto TeX reanuda la lectura de tokens desde su fuente de entrada anterior, que aquí sería texto leído de nuestro `.tex` archivo de entrada.

Como se muestra en el siguiente diagrama, TeX reanuda la lectura del `.tex` archivo de entrada en la ubicación exacta en la que se detuvo después de procesar `\\jobname`—después de leer el carácter de espacio pero antes de leer el carácter “.”. El punto (.) está, en la práctica, esperando a ser leído desde el búfer de entrada de TeX—una pequeña zona de la memoria de TeX diseñada para contener una línea de texto leída del `.tex` archivo—TeX lee y procesa tu `.tex` archivo una línea a la vez; no lee todo el archivo en la memoria.

Al estudiar el siguiente gráfico, léelo desde abajo y avanza hacia arriba para seguir el flujo del proceso.

![Cómo TeX expande \jobname](/files/f4a7244674976d3c0eab88e31144747c9ae0b716)

Volviendo a nuestra discusión sobre la expansión, podemos observar que la expansión de `\\jobname` dio como resultado que el `\\jobname` comando (token) fuera *eliminado* de la entrada y *reemplazado* por tokens surgidos de la expansión: la lista temporal de tokens generada para contener el nombre del `.tex` archivo.

Los comandos expandibles (como `\\jobname`) no son las únicas primitivas de TeX que “secretamente” crean y usan listas de tokens para lograr su efecto. Por ejemplo, los comandos `\\uppercase` y `\lowercase` ambos crean listas internas de tokens para cambiar el caso de su argumento. Una vez realizado el trabajo de cambio de mayúsculas/minúsculas, TeX pasa a leer tokens de caracteres de las listas de tokens generadas por esos comandos. Las listas de tokens son el único mecanismo de “almacenamiento de datos de tokens” de TeX, aparte de escribir datos en un archivo físico de disco.

### Fuentes de tokens: TeX es un maestro malabarista

Cuando TeX procesa un documento típico tiene que gestionar *muchas* fuentes de tokens: entrada procedente de numerosos archivos físicos de disco e innumerables listas internas de tokens creadas durante el procesamiento. En esta sección exploraremos muy brevemente cómo TeX logra “malabarear” esas fuentes de entrada.

Supongamos que queremos una macro simple que componga el nombre de nuestro `.tex` archivo:

```
    \def\myfile{El nombre de mi archivo es \jobname .tex}
```

Más adelante, en algún momento de nuestro `.tex` archivo, llamamos a la macro `\myfile`: temporalmente, TeX pasa de crear/leer tokens a través del texto en tu texto (`.tex`) a leer tokens desde la `\myfile` definición (lista de tokens) almacenada en su memoria. Cuando TeX ejecuta la `\myfile` macro (procesa sus tokens) detectará un token que representa el `\\jobname` comando, cuya expansión crea otra lista temporal de tokens de la que TeX tiene que leer tokens. Incluso en este escenario simple, TeX tiene que gestionar tres fuentes de entrada:

1. la `.tex` archivo de texto que contiene la `\myfile` macro;
2. la lista de tokens que almacena la definición de `\myfile` macro;
3. una lista de tokens creada por la `\\jobname` comando dentro del `\myfile` macro.

A medida que TeX procesa un documento, cambia constantemente entre fuentes de entrada: archivos físicos y listas de tokens, así que ¿cómo lleva TeX el control de esto? La respuesta es que, internamente, los motores de TeX mantienen una llamada [pila de entrada](https://en.wikipedia.org/wiki/Stack_\(abstract_data_type\)) que actúa como una especie de “memoria” que permite a TeX recordar lo que estaba haciendo (de dónde estaba leyendo) mientras cambia entre fuentes de entrada.

Sin entrar demasiado en los detalles, el código interno de los motores de TeX usa una variable global llamada `curinput` (entrada actual), que, entre otras cosas, le indica a TeX si actualmente está leyendo desde un archivo físico o una lista de tokens. `curinput` también indica a TeX la ubicación (en la lista de tokens actual o en su búfer de texto) desde la que debe obtener el siguiente token. Si TeX está leyendo desde una lista de tokens `curinput` también registra qué tipo de lista de tokens se está procesando; por ejemplo, la lista de tokens almacenada como una macro o si esos tokens surgieron de una fuente diferente.

Cuando es necesario, la `curinput` variable se modificará para apuntar a una nueva fuente de entrada y el “estado de entrada” actual de TeX (fuente y ubicación) se guardará en la pila de entrada para que TeX pueda regresar más tarde a esa ubicación exacta (posición en un `.tex` archivo o el siguiente token en una lista de tokens). Una vez que esa nueva fuente de entrada se agota (por ejemplo, ya no quedan tokens en la lista de tokens o se alcanza el final de un archivo), se saca de la pila y `curinput` se actualiza para asegurar que TeX vuelva a obtener tokens de la fuente anterior.

## Profundizando más (lectura opcional)

Las siguientes secciones proporcionan información de contexto adicional para los lectores que disfrutan de los detalles.

### Listas de tokens reales

El siguiente gráfico se generó usando la compilación personalizada de TeX de Knuth de Overleaf, que proporciona acceso a los datos internos y a las estructuras de datos de TeX. Esta ilustración de una lista de tokens se basa en la versión simplificada presentada arriba e incluye datos adicionales, como mostrar los caracteres generados por `\\jobname` tienen código de categoría 12, no el código de categoría habitual 11. En este diagrama, “nodo” es simplemente el nombre que se da a una unidad de almacenamiento de memoria utilizada por TeX.

![Dentro de una lista de tokens de TeX](/files/58ca3deb73b9f39824aad84614481ae0203deeae)

### Cómo TeX lee y procesa \jobname

Además, para mayor completitud, aquí hay una visión general de los “procesos de pensamiento” de TeX a medida que detecta `\\jobname` en nuestra entrada `.tex` archivo. En este gráfico vemos cómo TeX detecta un carácter de escape (`\` con código de categoría 0), procesa la secuencia de caracteres `jobname`, genera un token y busca el significado del `\\jobname` comando, donde TeX descubrirá que tiene un código de comando > 100, lo que indica que es un comando expandible.

![Cómo TeX escanea y procesa \jobname](/files/2a8d14e43e26c625196ebe4f42f53c0d869e640b)

[Parte 1](/latex/es/articulos-en-profundidad/19-how-does-expandafter-work-an-introduction-to-tex-tokens.md) [Parte 2](/latex/es/articulos-en-profundidad/22-how-does-expandafter-work-the-meaning-of-expansion.md) [Parte 3](/latex/es/articulos-en-profundidad/21-how-does-expandafter-work-tex-uses-temporary-token-lists.md) [Parte 4](/latex/es/articulos-en-profundidad/20-how-does-expandafter-work-from-basic-principles-to-exploring-tex-s-source-code.md) [Parte 5](/latex/es/articulos-en-profundidad/17-how-does-expandafter-work-a-detailed-macro-case-study.md) [Parte 6](/latex/es/articulos-en-profundidad/18-how-does-expandafter-work-a-detailed-study-of-consecutive-expandafter-commands.md)


---

# 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/21-how-does-expandafter-work-tex-uses-temporary-token-lists.md?ask=<question>&goal=<endgoal>
```

`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.
