> 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/mas-temas/18-how-overleaf-created-the-tex-primitive-reference-data.md). # Cómo Overleaf creó los datos de referencia de primitivas de TeX Este artículo describe los métodos y técnicas utilizados para producir las dos tablas de referencias cruzadas de comandos primitivos de TeX: * [Primitivos de TeX listados por motor TeX](/latex/es/mas-temas/46-tex-primitives-listed-by-tex-engine.md) y; * [Primitivos de TeX listados por el motor CJK TeX](/latex/es/mas-temas/45-tex-primitives-listed-by-cjk-tex-engine.md). Esta información se proporciona para los lectores interesados en los detalles más finos, pero no es un requisito previo para usar la propia tabla de referencias cruzadas. Para atender las necesidades de distintos lectores, ofrecemos una versión de resumen muy breve junto con una explicación más larga para quienes deseen explorar los temas con mayor profundidad. ## Versión breve de resumen/visión general Para construir la tabla de referencias cruzadas, Overleaf procesó el código fuente de 9 motores TeX para extraer la lista de primitivos admitidos por cada uno: ese proceso produjo 9 archivos de texto (1 archivo por motor TeX). Esos 9 conjuntos de primitivos se combinaron para crear una “lista maestra” que, en efecto, era la unión de los conjuntos individuales de primitivos: arrojando un total de alrededor de 1000 primitivos únicos repartidos entre los distintos motores. Para cada motor, su propia lista de primitivos se cruzó con el archivo maestro (el conjunto de todos los comandos) para determinar cuáles de esos \~1000 comandos admitía: esas comparaciones se tabulan en las dos tablas siguientes: * [Datos de referencia cruzada de primitivos de TeX](/latex/es/mas-temas/46-tex-primitives-listed-by-tex-engine.md) * [Datos de referencia cruzada de primitivos de TeX (para motores CJK)](/latex/es/mas-temas/45-tex-primitives-listed-by-cjk-tex-engine.md) ## “Creación de software” 101: ¿Qué significa eso? A lo largo del resto de este artículo hacemos referencia a la noción de “construir motores TeX”, que puede ser un concepto desconocido si no eres programador, o no programas en lenguajes compilados como C o C++. Para nuestros propósitos, construir software —es decir, motores TeX— es el proceso de crear un programa TeX ejecutable a partir de sus partes constituyentes: los archivos de código fuente escritos en el lenguaje de programación utilizado para desarrollar el programa. ## Versión completa: ¿Quieres los detalles? Sigue leyendo... Cada motor de composición tipográfica basado en TeX admite un “dialecto” del lenguaje TeX: un conjunto particular de comandos primitivos que controlan las funciones de composición tipográfica de cada motor y proporcionan los bloques de construcción para crear/definir macros: secuencias de comandos definidas por el usuario. Cada macro, ya esté escrita para LaTeX, plain TeX o cualquier otro paquete de macros, se construye en última instancia a partir de comandos primitivos, aunque puede que tengas que profundizar bastante, a través de capas de macros adicionales, antes de llegar a la “capa de base” de los primitivos de TeX. El conjunto de 9 motores TeX analizados para producir los datos de referencia de comandos primitivos, por supuesto, tienen muchos comandos en común, pero cada motor TeX también tiene sus propios comandos primitivos, añadidos por sus desarrolladores, para dar soporte a las características específicas de esa “versión” de TeX. Los comandos primitivos de un motor TeX están integrados en el software TeX ejecutable: los primitivos no son macros construidas por los usuarios, son instrucciones fundamentales, indivisibles/atómicas, que se utilizan para controlar el comportamiento de composición tipográfica de cada motor. En consecuencia, la forma más fiable de crear una lista definitiva de los comandos primitivos admitidos por cualquier motor TeX es examinar el código fuente real a partir del cual se construyen (compilan) los programas TeX ejecutables y extraer la lista de primitivos definida en el código fuente. Suena como si debiera ser fácil, ¿verdad? Sin embargo, debido a la historia de desarrollo de 40 años de TeX, explorar/examinar los archivos de código fuente de los motores TeX (excepto LuaTeX) no es particularmente sencillo. La razón de esas complejidades reside en las herramientas, el lenguaje de programación (Pascal) y la metodología (programación literaria) que Knuth utilizó para escribir el código fuente original de TeX, del que, en última instancia, descienden todos los demás motores. Señalamos una excepción para LuaTeX porque el código de su motor principal fue reescrito en C para eliminar el uso de Pascal y otras complejidades heredadas detalladas más abajo (Web2C); en consecuencia, aunque el código fuente de LuaTeX es extenso, la forma en que está “empaquetado” y distribuido es mucho más comprensible en comparación con otros motores TeX. Como consecuencia, y en función del flujo de trabajo/procesos utilizados para construirlos a partir del código fuente, conviene agrupar los motores TeX en dos categorías: 1. LuaTeX: proceso de compilación personalizado (más moderno) 2. Todos los demás motores: proceso de compilación heredado (Web2C) ## El contexto del código heredado: por qué construir (la mayoría de) los motores TeX es complejo Como exploraremos a continuación, Knuth publicó su código fuente original de TeX como un único archivo monolítico llamado `tex.web` que, cada 7 años, Knuth continúa actualizando para corregir los errores que queden; nunca se añaden nuevas funciones, es puramente un ejercicio de corrección de errores. La extensión del código fuente de TeX (`.web`) probablemente no te resulte familiar y quizá te preguntes ¿qué lenguaje utilizó Knuth para escribir TeX? La respuesta es Pascal, pero la `.web` extensión necesita algo más de explicación. Knuth desarrolló una metodología de programación a la que llamó [programación literaria](https://en.wikipedia.org/wiki/Literate_programming) en la que el código fuente de un programa y su documentación se combinan y se publican como un único archivo compuesto (código más documentación) con la extensión `.web`: ese tipo de archivo se denomina archivo WEB. Explicamos los archivos WEB con algo más de detalle a continuación. ### Creación de nuevos motores TeX: las estipulaciones de Knuth Aunque Knuth ha puesto desde hace mucho tiempo su código fuente de TeX (`tex.web`) a libre disposición de todos, sí impuso, como es su derecho absoluto, una estipulación clave: que su código fuente (`tex.web`) no debe editarse/modificarse directamente y redistribuirse con el nombre del programa “TeX”. En el código fuente escribe: ``` % Este programa es copyright (C) 1982 de D. E. Knuth; todos los derechos están reservados. % La copia de este archivo está autorizada solo si (1) eres D. E. Knuth, o si % (2) no haces absolutamente ningún cambio en tu copia. (El sistema WEB proporciona % para alteraciones mediante un archivo auxiliar; el archivo maestro debe permanecer intacto.) ``` y también: ``` Si este programa se cambia, el sistema resultante no debe llamarse `\TeX'; el nombre oficial `\TeX' por sí solo está reservado para sistemas de software que sean totalmente compatibles entre sí. Un conjunto de pruebas especial llamado la ``\.{TRIP} test'' está disponible para ayudar a determinar si una implementación particular merece ser conocida como `\TeX' [cf.~informe CS1027 de Stanford Computer Science, noviembre de 1984]. ``` En esencia: no hagas cambios editando y distribuyendo versiones modificadas del código fuente maestro de TeX y sigas llamándolo `tex.web`. Si realmente quieres hacer cambios, por ejemplo, añadir nuevos primitivos, etc., entonces debes aplicar esos cambios haciendo “alteraciones mediante un archivo auxiliar” y darle a tu programa “derivado de TeX” un nombre que lo distinga de “TeX”, que, en forma tipográfica ($$\mathrm\TeX$$), es una marca registrada de la American Mathematical Society. ### La herencia del legado Aunque ha habido intentos de reescribir completamente TeX usando lenguajes y metodologías de programación modernas —como las dos iniciativas basadas en Java [Nuevo Sistema de Composición Tipográfica](https://en.wikipedia.org/wiki/New_Typesetting_System) y [εχTEX](http://www.extex.org/) y otras como [una en Clojure](https://www.infoq.com/news/2015/01/implementing-tex-in-clojure), ninguna ha tenido un éxito completo. La historia de los proyectos e iniciativas diseñados para seguir desarrollando TeX es un tema interesante y quizá a los lectores les interese [visitar la FAQ de TeX del Reino Unido](https://texfaq.org/FAQ-enginedev) para obtener más información. Aquellas iniciativas no LuaTeX que también han tenido éxito, como e-TeX, pdfTeX, XeTeX y otros motores, se han construido *directamente sobre* el código original de Knuth: tomando su código fuente y “aplicando cambios” para derivar un nuevo motor con capacidades adicionales, como añadir nuevos primitivos, producir salida PDF, admitir entrada de texto UTF-8 y demás. Aunque ese camino ha conducido a éxitos notables, también significa que esos motores derivados heredan el código heredado y las técnicas de desarrollo que Knuth creó hace 40 años. La idea clave aquí es que, aparte de LuaTeX, la mayoría de los motores TeX derivados del código fuente original de Knuth se crean tomando un único archivo monolítico (normalmente `tex.web`) y aplicando cambios que generan otro único archivo monolítico que contiene el código fuente principal de ese nuevo motor. Los lectores avanzados quizá deseen saltar directamente a las [notas explicativas sobre pdfTeX y XeTeX](#aside-xetex-and-pdftex). ### Algo más de historia/contexto sobre TeX El momento de génesis de TeX fue [registrado en el diario de Knuth como el 30 de marzo de 1977](/latex/es/articulos-en-profundidad/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md#the-genesis-of-tex-a-brief-history), hace ya más de 40 años. Internamente, TeX es un programa extraordinariamente complejo cuyo código fuente Knuth se esforzó muchísimo por [documentar con un detalle excepcional](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373). Para ello, Knuth desarrolló un estilo de programación al que llamó [programación literaria](https://en.wikipedia.org/wiki/Literate_programming) en el que el código fuente y la documentación de un programa se combinan y se publican como un archivo compuesto con la extensión `.web` (denominado archivo WEB). Knuth eligió Pascal como lenguaje de programación para escribir su software TeX y, no sorprendentemente, utilizó el lenguaje de composición tipográfica TeX para escribir la documentación final. En consecuencia, el código fuente maestro de TeX de Knuth se publica como un único archivo monolítico llamado `tex.web`: una mezcla de código fuente en Pascal y código de composición tipográfica TeX para la documentación. Si un programa está escrito usando el estilo/metodología de programación literaria de Knuth (como ocurre con TeX, MetaFont, BibTeX y otros), necesitas preprocesar el archivo WEB para extraer la documentación o el código fuente. Para acceder a la documentación del programa procesas el archivo WEB (por ejemplo, `tex.web`) con una utilidad llamada [WEAVE](http://tug.org/texinfohtml/web2c.html#weave-invocation) que produce la documentación como un `.tex` archivo que puedes componer tipográficamente. Para extraer el código fuente en Pascal usas otra utilidad llamada [TANGLE](http://tug.org/texinfohtml/web2c.html#tangle-invocation) que genera un archivo con extensión `.p` que contiene código fuente en Pascal. En el momento de escribir esto (principios de 2019) la última versión del TeX de Knuth es 3.14159265, con fecha de enero de 2014. De nuevo, observa que el código fuente de TeX de Knuth está contenido en un solo archivo de alrededor de 25.000 líneas de código TeX/Pascal. ### De Pascal a C Durante los más de 40 años transcurridos desde el nacimiento de TeX, Pascal pasó de moda y hoy en día pocas, si es que alguna, personas contemplan construir TeX a partir de su código fuente original en Pascal. Para sortear el uso de Pascal por parte de Knuth, se diseñó un flujo de trabajo llamado [Web2C](http://tug.org/texinfohtml/web2c.html) (aprox. 1987) en el que el código fuente en Pascal de TeX se convierte mecánicamente (es decir, mediante software) a su equivalente en código C, que luego se usa para compilar TeX y construir el programa ejecutable. Funciona bien, pero el único inconveniente es que el código fuente en C generado mecánicamente no está pensado para una inspección humana casual: es *extremadamente* verboso y casi impenetrable, destinado a compiladores, no a personas; aquí hay una captura de pantalla que muestra un pequeño fragmento del código C generado a partir del código fuente en Pascal de TeX: ![](/files/670b00a1dfa405470bbccceb0fbef7d3921bc972) ### Otro knuthismo: archivos de cambios WEB Como se señaló arriba, para construir sobre el código fuente original de Knuth “aplicas cambios” o, en palabras de Knuth, haces “alteraciones mediante un archivo auxiliar”: pero, ¿qué significa esto realmente? Entra el *mecanismo de archivos de cambios*. ### Archivos de cambios: el mecanismo para crear nuevos motores TeX Los desarrolladores que desean ampliar TeX de Knuth de alguna manera, es decir, construir sobre el trabajo original de Knuth, normalmente desean crear una “versión” completamente nueva de TeX o proporcionar una *extensión* que pueda añadirse a cualquier motor TeX. Ejemplos de extensiones incluyen [SyncTeX](https://github.com/jlaurens/synctex) y [EncTeX](https://ctan.org/pkg/enctex?lang=en)—SyncTeX, por ejemplo, es una extensión muy útil que ahora está incluida en todos los motores TeX. La necesidad de EncTeX ha sido ampliamente superada por la evolución de los motores TeX conscientes de Unicode, pero observa que EncTeX está integrado en pdfTeX. Ya sea que el deseo sea producir una nueva “versión” de TeX (es decir, un derivado del TeX original de Knuth), o crear una extensión, sus desarrolladores comienzan con el código fuente original de Knuth y aplican las modificaciones necesarias para crear un nuevo motor TeX (o una extensión adicional). Sin embargo, como se señaló arriba, cualquiera que desee modificar el comportamiento de TeX necesita hacerlo usando “alteraciones mediante un archivo auxiliar”, porque esos cambios/modificaciones no deben aplicarse *directamente* editando el código fuente original de Knuth: los desarrolladores están obligados a usar el llamado WEB *mecanismo de archivos de cambios*. El código para modificar TeX de Knuth se escribe en el “lenguaje” WEB y se guarda en uno o más archivos de código (llamados *archivos de cambios*) que posteriormente se *fusionan* con el código fuente maestro original de Knuth, sin modificar. Ese proceso de fusión crea un nuevo archivo WEB compuesto que ahora contiene el *código* fuente principal del nuevo software basado en TeX, o modificado. *Los archivos de cambios* a menudo tienen la extensión `.ch` pero en la práctica pueden tener cualquier extensión que deseen los desarrolladores. #### ¿Cómo se usan/aplican los archivos de cambios? Hoy en día, la forma más sencilla de aplicar archivos de cambios y modificar un archivo WEB “maestro” es con un programa utilitario llamado [TIE](https://ctan.org/pkg/tie). Por ejemplo, supongamos que quisieras modificar TeX de Knuth añadiendo, por ejemplo, un par de nuevos primitivos o quisieras cambiar el comportamiento de un primitivo TeX existente (estándar). Escribirías tu código (¡en Pascal!) usando el sistema WEB de programación literaria y lo guardarías en un archivo llamado, por ejemplo, `myprim.ch`. El siguiente paso es fusionar tu código (en `myprim.ch`) con el archivo fuente maestro de Knuth `tex.web` y producir un nuevo archivo WEB compuesto que represente lo que llamaremos `mytex.web`. Para hacer esto simplemente ejecutas el programa TIE así: ``` tie -m mytex.web tex.web myprim.ch ``` Suponiendo que la fusión tenga éxito, esto dará como resultado un nuevo archivo WEB, `mytex.web`, dejando el archivo fuente maestro de Knuth `tex.web` completamente inalterado, como se requiere. Supongamos ahora que a otra persona le gustan los cambios que hiciste y quiere modificar tu trabajo para añadir sus cambios encima de, o además de, lo que tú has hecho. En lugar de distribuir tu versión modificada de TeX (`mytex.web`) decides publicar/compartir solo el archivo de cambios, `myprim.ch`. Cualquiera que quiera construir sobre tu trabajo puede ahora crear y compartir su archivo de cambios llamado, por ejemplo, `moreprim.ch` que amplía tu código de alguna manera. Cualquier otra persona que quiera aprovechar ambos archivos de cambios puede ahora generar un nuevo archivo WEB compuesto fusionando *ambos* archivos de cambios con el original de Knuth para generar otro programa TeX llamado, por ejemplo, `newmytex.web`: ``` tie -m newmytex.web tex.web myprim.ch moreprim.ch ``` ### Sistemas TeX reales: múltiples archivos de cambios La descripción anterior de TIE en realidad es muy cercana a la manera en que muchos motores TeX se construyen en la práctica: comienzan con el `tex.web` de Knuth y añaden una sucesión de archivos de cambios para generar el archivo fuente WEB de ese motor. Cada motor TeX requiere su propio conjunto particular de archivos de cambios, que deben aplicarse/procesarse (fusionarse) en un orden estricto: si te equivocas en el orden, el proceso de fusión fallará porque cada archivo de cambios de una secuencia depende de los cambios introducidos por los archivos de cambios que aparecen antes en la cadena. Aquí tienes una ejecución de ejemplo de TIE aplicando varios archivos de cambios al `tex.web` de Knuth para generar `ktex.web`—el archivo WEB compuesto con modificaciones al TeX de Knuth que lo dejan listo (adecuado) para su conversión a C mediante el proceso Web2C. Observa también lo siguiente: * `tex.ch` es un archivo de cambios muy grande que, entre muchas otras cosas, modifica TeX para usar Kpathsea; * la extensión SyncTeX se añade mediante varios archivos de cambios. ``` tie -m ktex.web tex.web tex.ch enctex.ch synctex-def.ch0 synctex-mem.ch0 synctex-mem.ch2 synctex-rec.ch0 synctex-rec.ch1 synctex-rec.ch2 tex-binpool.ch Este es TIE, CWEB Versión 2.4. Copyright (c) 1989,1992 por THD/ITI. Todos los derechos reservados. (tex.web) (tex.ch) (enctex.ch) (synctex-def.ch0) (synctex-mem.ch0) (synctex-mem.ch2) (synctex-rec.ch0) (synctex-rec.ch1) (synctex-rec.ch2) (tex-binpool.ch) ....500....1000....1500....2000....2500....3000....3500....4000....4500 ....5000....5500....6000....6500....7000....7500....8000....8500....9000 ....9500....10000....10500....11000....11500....12000....12500....13000 ....13500....14000....14500....15000....15500....16000....16500....17000 ....17500....18000....18500....19000....19500....20000....20500....21000 ....21500....22000....22500....23000....23500....24000....24500.... (No se encontraron errores.) ``` #### Nota aparte: XeTeX y pdfTeX Por completitud, debemos señalar que el proceso de compilación de pdfTeX y XeTeX en realidad no comienza con el `tex.web`de Knuth; en su lugar comienzan con archivos llamados `pdftex.web` y `xetex.web` respectivamente: presumiblemente porque los cambios son tan extensos que tiene más sentido compartir/publicar archivos WEB que ya contienen las modificaciones muy significativas hechas al código original de Knuth. ### Un ejemplo: e-upTeX La comunidad japonesa de TeX ha desarrollado una serie de motores TeX diseñados para atender las complejidades de la composición tipográfica del texto japonés: * **pTeX**: motor TeX de Knuth ampliado para admitir la composición tipográfica en japonés; * **e-pTeX**: una combinación de e-TeX y pTeX (más unos pocos primitivos introducidos por pdfTeX); * **upTeX**: una versión de pTeX consciente de Unicode más extensiones para un mejor manejo de CJK (chino, japonés y coreano); * **e-upTeX**: una combinación (fusión) de e-TeX y upTeX. #### Generación del archivo fuente compuesto para e-upTeX Para crear el archivo fuente WEB compuesto para e-upTeX (con SyncTeX) comienzas con el `tex.web` de Knuth, pero necesitas aplicar **26** archivos de cambios individuales, en el siguiente orden, para obtener un único archivo compuesto del que se pueda extraer la lista de comandos primitivos: ``` etex.ch, tex.ch0, tex.ch, tex.ech, etex.ch0, ptex-base.ch, uptex-m.ch, euptex.ch0, eptex.ech, etex.ch1, euptex.ch1, synctex-def.ch0, synctex-ep-mem.ch0, synctex-mem.ch0, synctex-e-mem.ch0, synctex-ep-mem.ch1, synctex-p-rec.ch0, synctex-rec.ch0, synctex-rec.ch1, synctex-e-rec.ch0, synctex-p-rec.ch1, fam256.ch, pdfstrcmp-eup-pre.ch, pdfutils.ch, pdfstrcmp-eup-post.ch, tex-binpool.ch ``` #### Aplicación de archivos de cambios: ¿qué archivos y en qué orden? Como se indicó, es crucial aplicar/procesar los archivos de cambios en un orden estricto, pero ¿cómo averiguas qué archivos se necesitan y en qué orden procesarlos? Afortunadamente, esa información crucial está registrada dentro de archivos contenidos en la distribución TeX Live y una exploración del código fuente de TeX Live reveló las reglas que rigen los requisitos de compilación de cada motor TeX. Siguiendo esas reglas, Overleaf pudo reconstruir el archivo fuente WEB compuesto de cada motor TeX y extraer una lista de primitivos para el procesamiento posterior de datos. ## Y por último: ¿cómo extraer la lista de primitivos? Una vez construido el archivo WEB compuesto, la tarea de extraer la lista de primitivos, usando expresiones regulares, es sencilla porque todos los comandos primitivos se definen (“registran”) mediante una única función Pascal llamada `primitive(...)`. Aquí hay algunos ejemplos reales tomados del código fuente de Knuth: `tex.web` código fuente: ``` primitive("lineskip",assign_glue,glue_base+line_skip_code) primitive("baselineskip",assign_glue,glue_base+baseline_skip_code) primitive("parskip",assign_glue,glue_base+par_skip_code) primitive("abovedisplayskip",assign_glue,glue_base+above_display_skip_code) primitive("belowdisplayskip",assign_glue,glue_base+below_display_skip_code) primitive("abovedisplayshortskip",assign_glue,glue_base+above_display_short_skip_code) ... ... ``` Como puedes ver, la `primitive(...)` función es muy adecuada para el procesamiento de texto con expresiones regulares: el nombre del primitivo que se está registrando está entre comillas (`"..."`) junto con datos adicionales que clasifican el comportamiento de cada primitivo (no consideraremos eso con ningún detalle). Después de extraer la lista de primitivos para cada motor, esos datos fueron procesados por algunos scripts de Lua para generar HTML que contiene los resultados tabulados. ### Volviendo a LuaTeX Hemos señalado que LuaTeX no utiliza exactamente los mismos procesos de compilación que los otros 8 motores TeX. Tras explorar brevemente el proceso Web2C, la conversión de Pascal a C y el mecanismo de archivos de cambios, ahora podemos explicar en qué se diferencia LuaTeX: los desarrolladores de LuaTeX decidieron prescindir del engorroso proceso de convertir Pascal a C, como se señala en [El Manual de Referencia de LuaTeX](http://www.pragma-ade.com/general/manuals/luatex): > ...el marco de compilación es web2c y seguimos usándolo, pero sin el paso de Pascal a C. El motor principal de LuaTeX fue reescrito en C, lo que significa que su proceso de compilación es algo más estándar y, sin duda, mucho más conveniente. Una consecuencia útil es que los primitivos admitidos por LuaTeX están bien separados en un archivo fuente C independiente, lo que facilitó considerablemente la tarea de acceder a ellos/listarlos. En sentido estricto, también debemos señalar que algunos de los archivos fuente de LuaTeX utilizan una variante de la metodología de programación literaria de Knuth, llamada [CWEB](https://en.wikipedia.org/wiki/CWEB), basada en C y no en Pascal. ### No solo archivos WEB: se requiere otro código fuente Después de generar el archivo fuente WEB compuesto para cualquier motor TeX (excepto LuaTeX), hay que extraer el código fuente en Pascal y convertirlo a código C, pero eso no es la solución total. Además del código C generado a partir del fuente WEB (Pascal⮕C), la mayoría de los motores TeX también dependen (requieren) de una serie de archivos fuente auxiliares adicionales (bibliotecas) que normalmente están escritos en C, como [Kpathsea](https://www.tug.org/kpathsea/). Los archivos fuente auxiliares (bibliotecas) implementan funcionalidades que no necesitan, o no pueden, escribirse en WEB (Pascal). Todo lo que se escriba en el “lenguaje” WEB para TeX tiene que usar el lenguaje Pascal, que luego se extrae y se convierte en C generado por máquina: si no necesitas hacer eso, ¿por qué no escribirlo simplemente en C o C++ desde el principio? --- # 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/mas-temas/18-how-overleaf-created-the-tex-primitive-reference-data.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.