> 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/it/articoli-approfonditi/54-what-is-a-tex-token-list.md). # Che cos'è una lista di token TeX ## Quindi, che cos’è esattamente una «lista di token TeX»? In un [articolo precedente](/latex/it/articoli-approfonditi/53-what-is-a-tex-token.md)—anch’esso parte di questa [serie sulle tecnicalità di basso livello di TeX](/latex/it/articoli-approfonditi/01-a-new-series-of-articles-tex-tokens-and-related-concepts-but-why-and-how.md)—abbiamo esplorato i processi attraverso i quali TeX esamina il tuo `.tex` file per generare nuovi token: abbiamo esaminato la natura fondamentale di un token TeX e come TeX li crea (vedi [Che cos’è un «token TeX»?](/latex/it/articoli-approfonditi/53-what-is-a-tex-token.md)). In questo articolo di approfondimento diamo uno sguardo *lista di token*s: che cosa sono e come i motori TeX li creano/usano. Acquisire una comprensione delle liste di token può essere complicato perché sono memorizzate in profondità nelle interne di TeX: questi dettagli sono nascosti all’utente—anche se, oggi, non è sempre vero se si fa programmazione più avanzata con LuaTeX. Per ora, però, puoi iniziare a pensare alle liste di token come al modo in cui TeX memorizza una serie di valori interi, dove ogni intero è un token derivato da un carattere o da un comando che TeX ha letto dal tuo file di input. Le liste di token svolgono un ruolo fondamentale nel funzionamento interno di TeX, spesso in modi sorprendenti, come nel funzionamento interno di comandi come `\uppercase` e `\lowercase`. Un uso particolarmente importante delle liste di token è la memorizzazione e l’esecuzione delle macro, un argomento che esamineremo in dettaglio come parte di un futuro articolo di questa serie. ### TeX riceve il suo input da file e liste di token I motori TeX hanno tre sorgenti di input—due che potresti conoscere: * file di testo fisici memorizzati sul disco; * testo che un utente digita nel terminale (riga di comando); ma ha anche un terzo modo di leggere/ottenere input: le liste di token! Le liste di token sono, in effetti, una struttura interna di memorizzazione dei dati che TeX usa come parte delle sue operazioni. Poiché le liste di token di TeX fungono da «struttura di memorizzazione» per token creati in precedenza, ha senso che TeX possa riutilizzarle come un’altra sorgente di input. Quando diventa necessario prendere il prossimo input da una particolare lista di token (o TeX viene istruito a farlo), TeX interromperà temporaneamente la lettura dell’input da un file fisico (cioè la creazione di *nuovi token*) e passerà a ottenere il suo input da *token esistenti*: la posizione in memoria in cui è memorizzata la lista di token. Chiaramente, con una lista di token il processo di scansione + generazione dei token è già avvenuto, quindi TeX deve solo guardare ciascun token della lista e decidere cosa fare con ciascuno di essi. Come rapido esempio, il comando di basso livello (primitiva TeX) `\toks` ti permette di creare una lista di token che TeX salva in memoria per un successivo riutilizzo: ```latex \toks100={Hello} ``` Per recuperare quei token (cioè dire a TeX di trattarli come sua prossima sorgente di input) si dovrebbe usare un comando come ```latex \the\toks100 ``` Questo farà sì che TeX passi dalla creazione di nuovi token dal tuo file di input all’ottenimento del prossimo da dove sono memorizzati quei token (creati da `\toks`)—in un cosiddetto *registro di token* che non è altro che una posizione di memoria interna nota a TeX (qui è il registro 100). Inoltre, le liste di token possono essere generate internamente, al volo, da numerosi comandi TeX. Un esempio è il comando `\jobname` che genera una serie di token di carattere—un token per ciascun carattere del nome del file principale che TeX sta elaborando. Un altro esempio è il comando `\string` ; per esempio ```latex \string\mymacro ``` genera una serie di token di carattere per ciascuna lettera del nome `\mymacro`—incluso il carattere iniziale `\` . Esaminiamo più da vicino alcuni «comandi generatori di token» alla fine di questo articolo. ## Lista di token: spiegata per analogia A meno che tu non abbia un background di programmazione e/o qualche conoscenza di informatica, le «liste di token» possono essere un concetto un po’ sfumato e, forse, un po’ confuso. Tuttavia, se desideri diventare competente nello scrivere macro TeX/LaTeX, allora una buona comprensione di argomenti come token TeX, liste di token e codici di categoria (`\catcode`) si rivelerà estremamente utile. In questa sezione useremo un’analogia per spiegare/illustrare le idee/principi fondamentali di una lista di token TeX: come TeX memorizza i token in memoria. Vale la pena dedicare del tempo a leggere attentamente questa parte perché le liste di token sono un aspetto *fondamentale* di TeX e vale la pena capirlo un po’ più in dettaglio. ### Liste di token: un’analogia (esperimento mentale) Faremo un «esperimento mentale» per fornire una base alla comprensione delle liste di token TeX. Immagina di avere accesso a un grande insieme di contenitori, come centinaia di barattoli—non possiamo considerare o usare il termine «scatola» per descrivere i contenitori del nostro esperimento mentale perché, ovviamente, «box» ha un significato molto specifico in TeX, del tutto estraneo alla nostra discussione qui. Quindi chiameremo i nostri contenitori «barattoli», dove ogni Barattolo: * ha un numero identificativo unico stampato all’esterno; * è (internamente) suddiviso in due scomparti. Quei due scomparti sono progettati così: * il compartimento di sinistra contiene l’oggetto che vuoi mettere nel Barattolo; * il compartimento di destra è progettato per contenere un pezzo di carta sul quale puoi scrivere un singolo numero: il numero che identifica un altro Barattolo. ![test](/files/a3d75dfd3e6316bcd1d2c1e612f77bb08ffd47c2) Supponi di avere una raccolta di, diciamo, 5 oggetti e di voler memorizzare quella raccolta di oggetti all’interno di quei Barattoli; ma, ahimè, ogni Barattolo può contenere solo 1 oggetto del tipo che vuoi memorizzare. Per semplicità, supponiamo di voler memorizzare 5 cerchi colorati: ![{{{alt}}}](/files/34f639cac9d5440e2a7d903cc79e3598d3dd678c) Inoltre, quando torni a recuperare quegli oggetti dal tuo sistema di memorizzazione (Barattoli), quegli oggetti *devono* essere recuperati/trovati in un ordine particolare—l’ordine in cui sono stati memorizzati: quella sequenza deve essere preservata. Come puoi ottenere questo? Possiamo sfruttare il fatto che ogni Barattolo: * ha un numero identificativo unico attaccato all’esterno; * ha 2 scomparti—solo 1 dei quali useremo per contenere il nostro oggetto, l’altro contiene un pezzo di carta con scritto il numero di un altro Barattolo. Assumeremo che ogni Barattolo sia vuoto—ma nulla ti impedisce di aprire un Barattolo specifico per controllare se è vuoto; se non lo è, prova il successivo finché non trovi un Barattolo vuoto. Quello che potremmo fare è il seguente. Metti il nostro primo oggetto (cerchio verde scuro) in uno dei nostri Barattoli (ad es., Barattolo 124) e annota il numero di questo primo Barattolo—non importa quale numero abbia quel primo Barattolo, ciò che conta è che lo scriviamo da qualche parte e lo salviamo per un uso successivo. ![{{{alt}}}](/files/4acae385966d65fbc22a54d6e05cc1f40d84a44f) Trova un secondo Barattolo—qualsiasi numero di Barattolo (ad es., Barattolo 432)—e annotane il numero. Scrivi il numero di quel secondo Barattolo (432) su un pezzo di carta e metti quella nota *nel primo Barattolo* (Barattolo 124). Mettiamo il nostro secondo oggetto (cerchio verde chiaro) nel secondo Barattolo. Quindi, al momento abbiamo la seguente situazione: * una nota scritta—non memorizzata in un Barattolo—che afferma che il primo Barattolo è il numero 124 (contiene il nostro primo oggetto); * all’interno del Barattolo 124 abbiamo aggiunto un’altra nota che dice che il prossimo oggetto si trova nel Barattolo 432. In sostanza, abbiamo *collegato* i nostri primi due Barattoli: sappiamo da dove iniziare (Barattolo 124) e che una nota nel Barattolo 124 ci dice quale Barattolo contiene il prossimo oggetto (Barattolo 432). ![{{{alt}}}](/files/d740fff752061de51b1e2d8a3457d31c4d67269f) Poi troviamo un terzo Barattolo, scriviamo il suo numero (ad es., Barattolo 543) su un pezzo di carta e lo mettiamo nel *secondo* Barattolo (numero 432). Poi mettiamo il nostro terzo oggetto (cerchio rosso) nel terzo Barattolo. Ora abbiamo collegato tre Barattoli nella sequenza: il nostro punto di partenza, Barattolo 124 (cerchio verde scuro) → Barattolo 432 (cerchio verde chiaro)→ Barattolo 543 (cerchio rosso) →… ![{{{alt}}}](/files/6dee33921baf621d8cfe25b42ac6058bb27a8bb8) Ripeti questo processo per gli ultimi due oggetti (cerchi azzurro chiaro e blu scuro) usando Barattolo 213 (cerchio azzurro chiaro) e Barattolo 102 (cerchio blu scuro). ![{{{alt}}}](/files/f7f17b4921e61cec9941beafde1ca15a28f905c4) Ora abbiamo tutti e 5 i Barattoli collegati insieme (usando l’identificativo numerico di ciascun Barattolo) e siamo in grado di recuperare tutti i nostri oggetti memorizzati—nel giusto ordine—semplicemente visitando ogni Barattolo a turno, rimuovendo il nostro oggetto e guardando la nota che ci dice quale Barattolo contiene il nostro prossimo oggetto. ### E che dire dell’ultimo oggetto della nostra lista (Barattolo 102)? Perché dovremmo preoccuparci di questo in particolare? Finora abbiamo memorizzato ogni oggetto in un Barattolo, insieme a una nota che dice quale Barattolo contiene l’oggetto successivo: per l’ultimo oggetto della nostra lista cosa dovrebbe dire quella nota—perché non esiste un Barattolo successivo. Quando arriviamo all’oggetto finale (Barattolo) deve essere ovvio che questo Barattolo (contenente l’ultimo oggetto) è l’elemento finale della nostra lista—non dobbiamo cercare un altro Barattolo, perché non c’è. Un modo per farlo è usare un numero di Barattolo «speciale» all’interno del nostro Barattolo finale (102). Possiamo usare qualsiasi numero desideriamo purché scegliamo un numero univoco che non sia il numero di un Barattolo reale—per esempio «Barattolo -1», «Barattolo 0»: non importa, purché sappiamo che «Barattolo -1» o «Barattolo 0» ecc. ci dica immediatamente di smettere di cercare: non dobbiamo cercare altri Barattoli perché questo è l’ultimo e quindi non ci sono più oggetti da recuperare. ### Da «oggetti» e «Barattoli» a token e TeX Ora dobbiamo passare dalla nostra analogia a una descrizione più vicina alla realtà di TeX. Innanzitutto, invece di memorizzare cerchi di colori diversi nei nostri Barattoli immaginari dovrebbe essere chiaro che possiamo pensare a quei Barattoli come a contenitori di token TeX: semplici interi. Questa è la parte più facile del trasferire la nostra analogia nel regno del software (TeX). Ma quale potrebbe essere l’equivalente software dei nostri Barattoli fisici numerati con «scomparti»? Non vogliamo addentrarci troppo nei concetti di programmazione, ma puoi pensare ai nostri «Barattoli» come a rappresentazioni di alcuni byte di memoria del computer che sono stati «impacchettati» in un’unità di memorizzazione comoda. L’uso di un identificativo numerico per ciascun Barattolo può essere considerato come la posizione all’interno della memoria del computer in cui si trova ciascun piccolo pacchetto di memoria. All’interno di TeX, quei piccoli pacchetti di memoria sono chiamati «memory words»—un termine che riflette il tempo/l’epoca in cui TeX è stato creato (anni ’70). Queste «memory words» sono il mattone fondamentale usato all’interno di TeX, ma non abbiamo bisogno di esaminarle in dettaglio qui—chi desidera ulteriori dettagli può fare riferimento a un articolo sul [blog personale dell’autore](http://www.readytext.co.uk/?p=3537). In termini di programmazione, ciò di cui abbiamo parlato si chiama [*lista concatenata*](https://en.wikipedia.org/wiki/Linked_list): una lista di token TeX è una lista concatenata costruita a partire dai contenitori di memorizzazione di TeX chiamati *memory words* dove ogni memory word può essere usata per memorizzare: * un *valore*: il valore del token (un intero); * un *collegamento*: la posizione di memoria della memory word successiva contenente il token successivo nella nostra lista. ## Dove usa TeX le liste di token? Ovunque! Questo è vero perché una definizione di macro TeX/LaTeX (ad es., un comando LaTeX) è memorizzata come una forma (leggermente specializzata) di lista di token—specializzata nel senso che contiene token che non vedi nelle liste di token «standard» (relativi alla corrispondenza dei parametri della macro ecc.). Non preoccuparti di questo perché affronteremo questi dettagli in un futuro articolo. ### Un esempio di macro Una macro può essere considerata composta da tre parti: ``` \def\{} ``` Nota che invece di `\def` avresti potuto usare `\edef`, `\gdef` o `\xdef`. **Nota per gli utenti LaTeX**: qui stiamo definendo macro usando comandi grezzi, di basso livello, di TeX (chiamati *primitivi*). Gli utenti LaTeX saranno più familiari con la creazione di macro tramite `\newcommand` di LaTeX (che è a sua volta una macro). Quando chiedi a TeX di creare (definire) una macro, esso creerà un token che rappresenta il `` e un *lista di token* che rappresenta il combinato `` e ``. TeX memorizzerà tutto con cura in modo che il token che rappresenta `` sia collegato alla lista di token che rappresenta la sua definizione (`` e ``). Per esempio, se definiamo `\mymacro` così: ```latex \def\mymacro abc #1 defz{Ho digitato "#1"!} ``` Possiamo vedere che le sue parti costituenti sono: * `` = `mymacro` * `` = `abc #1 defz` * `` = `Ho digitato "#1"!` Per esempio, potresti chiamare `\mymacro` così: ```latex \mymacro abc THIS TEXT defz ``` che produce `Ho digitato "THIS TEXT"!` essere composto tipograficamente—i `abc` e `defz` sono *non* composti tipograficamente. `abc` e `defz` sono sequenze di token di carattere usate per *delimitare* il parametro della macro `#1` e vengono assorbiti e scartati quando la chiamata alla tua macro viene elaborata con successo da TeX. Quando hai definito `\mymacro`, il modello di token contenuto nella memorizzazione agisce come una «modello» che TeX può usare per capire: * quali token nel tuo input sono i token delimitatori; * quali token nel tuo input formano effettivamente il/i parametro/i della tua macro (qui, ciò che stai usando per `#1` nella tua chiamata di `\mymacro`). Devi chiamare `\mymacro` con un `` contenente delimitatori identici a quelli usati per definirla—incluso l’uso di delimitatori di carattere con codici di categoria identici. Se i delimitatori nel `` usati per chiamare `\mymacro` sono diversi da quelli usati per definirla (il «modello» memorizzato in memoria), allora TeX può diventare piuttosto confuso—quando cerca di elaborare `\mymacro` non sarebbe in grado di far corrispondere il «modello» che ha salvato nella sua memoria. Quando TeX vede che stai chiamando una macro, esaminerà il tuo testo di input per creare nuovi token e proverà, token per token, a confrontarli con la lista di token `` modello memorizzata come parte della definizione della tua macro. Se i delimitatori usati nel tuo testo di input producono una serie di token che non corrispondono a quelli memorizzati nel «modello», allora TeX di solito segnalerà un errore. TeX è molto preciso—ricorda che i token di carattere sono una combinazione di codice del carattere e codice di categoria: se cambi il codice di categoria di un carattere ottieni un valore di token diverso risultante da quel carattere. Supponiamo di cambiare il codice di categoria di `z` in, diciamo, 12—normalmente è 11—e proviamo a chiamare la nostra macro così: ```latex \catcode`z=12 \mymacro abc THIS TEXT defz more text here... ``` Questa volta non funzionerà perché il codice di categoria di `z` è stato cambiato. Vedrai un errore come questo: ```latex Argomento in fuga? THIS TEXT defz ! Il paragrafo è terminato prima che \mymacro fosse completo. \par l.22 ``` Quando TeX legge e scansiona il `z` in `defz` non riesce a riconoscerlo come la fine di `\mymacro`’s `` usato nel tuo file di input. Fino a vedere quel `z` TeX aveva correttamente abbinato i primi 3 caratteri `def` ma quel `z` (con codice di categoria 12) manda in crisi la scansione di TeX. Supponendo che `z` avesse un codice di categoria 11 quando abbiamo *definito* `\mymacro`: ciò comporterebbe che un valore di token pari a 256×11 + 122 = 2938 venga memorizzato come parte della `\mymacro`’s definition (cioè memorizzato come parte del «modello»). Tuttavia, con codice di categoria 12, `z` creerà ora un valore di token pari a 256×12 + 122 = 3194. Poiché il valore del token (per `z`) letto dal tuo input (valore 3194) non corrisponde al token `z`contenuto nel modello della lista di token memorizzata (valore 2938), TeX continuerà a scansionare il tuo input. TeX continuerà a scansionare il testo successivo alla tua macro ( `` more text here*...) per cercare ulteriori token—provando a far corrispondere il modello memorizzato con i token che trova nel tuo input. Probabilmente non troverà il corretto schema di token e si verificheranno errori, poiché TeX «oltrepasserà» il tuo input e leggerà erroneamente testo extra per creare ulteriori token—quei token extra non avrebbero dovuto essere letti a questo punto e quasi certamente genereranno un errore.* Approfondiremo questo aspetto in un futuro articolo. Approfondiremo questo aspetto in un futuro articolo. ## Altri usi delle liste di token Altri comandi usati per creare/memorizzare liste di token includono: ```latex \toks={...} \everypar={...} \everymath={...} \everydisplay={...} \everyhbox={...} \everyvbox={...} \output={...} \everyjob={...} \everycr={...} \errhelp={...} ``` Ciascuno di questi comandi crea una lista di token a partire dai caratteri e dai comandi all’interno delle parentesi graffe ‘{...}’ e quella lista di token è destinata a essere riutilizzata in determinate circostanze. Per esempio, `\everypar={...}` crea e memorizza un insieme di token (una lista di token) che TeX inserisce nell’input poco prima di iniziare un nuovo paragrafo. ## Usi nascosti delle liste di token: esempi In questa sezione finale esamineremo alcuni esempi pratici di liste di token usate in modi che potresti non aspettarti. ### Esempio 1: \uppercase{...} e \lowercase{....}—liste di token temporanee Oltre ai comandi espliciti per generare liste di token, ci sono circostanze in cui TeX genera una lista di token interna nascosta e temporanea per eseguire qualche elaborazione speciale. Ricorda che quando TeX legge/elabora i tuoi caratteri/comandi di input essi vengono trasformati in token: il mattone fondamentale con cui lavorano i motori TeX. Un buon esempio sono i comandi `\uppercase{...}` o `\lowercase{...}` perché il loro funzionamento può, a prima vista, essere piuttosto confuso. Una volta che capisci cosa stanno facendo—più in profondità dentro TeX e invisibile all’utente—il loro funzionamento diventa molto più facile da comprendere. Supponi di avere una semplice serie di lettere che vuoi mettere in maiuscolo—ad es. abcde e convertirla in ABCDE. Bene, è abbastanza semplice con il comando `\uppercase` di TeX: ```latex \uppercase{abcde} ``` farà sì che TeX produca `ABCDE`. Ora supponiamo di voler salvare la nostra semplice serie di lettere per usarla più tardi—cioè non vogliamo produrle subito, quindi useremo l’unico meccanismo *interno* di TeX—non un meccanismo esterno (file)—per salvare i dati: usa una lista di token. Possiamo farlo creando una macro oppure usando un comando esplicito per liste di token: ```latex \toks100={abcde} \def\mychars{abcde} ``` Poi, a un certo punto, potresti decidere di voler riutilizzare la tua serie di lettere ma, questa volta, in maiuscolo; quindi provi ```latex \uppercase{\the\toks100} ``` e ```latex \uppercase{\mychars} ``` Ma, ahimè, nessuno di questi funziona. Perché? ### Liste di token segrete! Per capire come funzionano realmente i comandi `\uppercase{...}` `\lowercase{...}` ho dovuto sbirciare nei meccanismi interni di TeX, quindi la seguente spiegazione ne deriva. Quando TeX rileva `\uppercase{}` o `\lowercase{}` nel tuo input, la prima cosa che fa TeX è creare una lista di token interna (temporanea) dal `` racchiuso tra le ‘{’ e ‘}’ che seguono dopo i `\uppercase{...}` o `\lowercase{...}` comandi—quella lista di token temporanea è interna a TeX. Un punto cruciale, centrale per capire come `\uppercase{}` e `\lowercase{}` funzionano realmente, è che eventuali comandi o macro contenuti nel `` non *vengono espansi*: tutto ciò che fa TeX è generare token da caratteri e comandi posti tra `{...}`. Durante il funzionamento di `\uppercase{}` o `\lowercase{}` nulla tra le parentesi graffe viene eseguito: viene semplicemente trasformato in token. Dopo che il `` all’interno del `{...}` è stato convertito in una lista di token (temporanea), TeX rivede poi ogni token di quella lista e verifica se è un *carattere* token o un token di *comando* (usando il valore numerico del token). Se TeX rileva un token di carattere modifica quel token per regolare il maiuscolo/minuscolo del carattere (a seconda che `\uppercase` o `\lowercase` sia in fase di elaborazione). TeX semplicemente ignora eventuali token di comando e non «guarda dentro» alcun token di comando per vedere cosa rappresentino o contengano (ad es. una macro che contiene caratteri)—vengono semplicemente saltati: solo i token di carattere vengono effettivamente elaborati/alterati dalle operazioni di cambiamento di maiuscole/minuscole. Quindi, per esempio, se emettiamo un comando TeX come `\uppercase{abcde}` TeX creerà una lista di token da `abcde` contenente nient’altro che token di carattere: vengono tutti regolati per creare una serie di token modificati che rappresentano A, B, C, D ed E. Quei token modificati vengono rimandati al processore di input di TeX, il che produce `ABCDE` essere composto tipograficamente. Tuttavia, se abbiamo memorizzato i nostri caratteri *all’interno di una macro*—per esempio `\def\mychars{abcde}`—e proviamo a convertirli in maiuscolo così: ```latex \uppercase{\mychars} ``` allora fallirà e verrà composto abcde—not ABCDE come potresti aspettarti. Se poi proviamo a memorizzare i nostri caratteri in una lista di token come `\toks0={abcde}` e fare `\uppercase{\the\toks0}` allora, ancora una volta, `\uppercase` fallirà perché la lista di token sarà composta interamente da token che non sono influenzati da `\uppercase`. Prendendo l’esempio della nostra macro, `\mychars`, dopo che TeX rileva `\uppercase` nell’input, TeX cerca il significato di `\uppercase` e lo esegue, creando una lista di token temporanea da `{\mychars}`. Chiaramente, quella lista di token temporanea contiene un solo token che non è un token di carattere ma uno che rappresenta il nostro comando macro `\mychars`: quindi, ai fini dell’esecuzione di `\uppercase`, quel token viene ignorato—`\mychars` non rappresenta un token di carattere. Tuttavia, come notato sopra, una volta che `\uppercase` ha fatto il suo lavoro, la lista di token temporanea (creata dall’azione di `\uppercase`) viene reimmessa nel meccanismo completo di elaborazione dell’input (scansione) di TeX. Quando TeX rilegge quella lista di token rileva un token che rappresenta la nostra `\mychars` macro che TeX esegue (espande) e genera una serie di caratteri da comporre, abcde—sempre in minuscolo perché erano stati «impacchettati» dentro una macro e quindi invisibili alle azioni di `\uppercase`. Una volta che TeX ha riesaminato la lista di token temporanea creata per `\uppercase{...}` o `\lowercase{...}`, e ha elaborato eventuali token di carattere, passa quindi a usare quella lista di token temporanea come sorgente del suo input: componendo i caratteri (token di carattere elaborati) ed eseguendo comandi e macro. ### Come si può risolvere questo problema? Poiché `\uppercase{...}` o `\lowercase{...}` agirà solo sui token di carattere, abbiamo bisogno di un modo per «forzare il disimballaggio» dei caratteri contenuti nella nostra macro `\mychars` (o contenuti in un `\toks` registro) prima che `\uppercase{...}` o `\lowercase{...}` agisca su di essi. Con «disimballaggio» intendiamo in realtà il processo di TeX di *espansione*: * sostituzione di un comando TeX/LaTeX con la *sequenza* di token *da cui quel comando* (*ad es., una macro*) *è composto,* o * producendo la sequenza di token che un comando è progettato per *generare*. Un esempio di comando che genera token è `\jobname`, che produce una sequenza di token di carattere che rappresentano il nome del file TeX principale in elaborazione. #### Magia di livello inferiore: scantoks(..., ...) Qui stiamo davvero esplorando alcuni angoli più oscuri del funzionamento interno di TeX, quindi puoi ignorare questa sezione a meno che tu non apprezzi i dettagli… Dopo che TeX rileva `\uppercase` o `\lowercase` nel flusso di input, esegue una funzione interna chiamata `scantoks(..., ...)` il cui compito è generare l'elenco di token usando gli elementi tra la ‘{’ di apertura e la ‘}’ di chiusura—come discusso, quell'elenco di token viene successivamente esaminato per individuare (e quindi adattare) eventuali token di carattere per modificare la maiuscola/minuscola dei caratteri come richiesto. Nota attentamente che ci stiamo riferendo a `scantoks(..., ...)` come alla funzione interna integrata nel codice sorgente dei motori TeX—qui non la si sta indicando come nome di una sequenza di controllo. Come parte del suo lavoro, `scantoks(..., ...)` può essere istruita se espandere o non espandere l'elenco di token che sta costruendo e per `\uppercase` e (`\lowercase`) non espande i token: si limita a crearli e a inserirli in un elenco di token. Una delle prime cose che `scantoks(..., ...)` deve fare è controllare la presenza di una ‘{’ di apertura (o di qualsiasi carattere con `\catcode` codice di categoria 1) perché deve assicurarsi che l'utente non abbia commesso un errore di sintassi e dimenticato la ‘{’ di apertura (o qualsiasi carattere con codice di categoria 1)—perché un carattere con codice di categoria 1 è necessario per delimitare l'inizio di un elenco di elementi da tokenizzare. Ed ecco il trucco: il compito di cercare una ‘{’ di apertura attiva `scantoks(..., ...)` l'esecuzione del processo di espansione di TeX, il che significa che i seguenti esempi funzioneranno: ```latex \\let\\ob={ \\uppercase\\ob abcde} \\def\\obb{\\ob} \\uppercase\\obb xyz} ``` Prendendo l'esempio di `\\obb`, una macro, viene riconosciuta come un *comando espandibile* e viene opportunamente espansa da TeX (tramite la `scantoks(..., ...)` funzione) nella sua ricerca di una parentesi graffa di apertura (qualsiasi carattere con codice di categoria 1). Questo significa che possiamo usare il “`\\expandafter` trucco” per raggiungere il nostro obiettivo di “decomprimere” i nostri caratteri dai confini della macro—cioè espanderla. Nota che `\\expandafter` rientra anch'esso nella categoria di essere un *comando espandibile*, quindi TeX lo attiva qui e gli lascia svolgere il suo lavoro come parte della ricerca di una ‘{’ di apertura (o di qualsiasi carattere con codice di categoria 1). Quindi, se definisci: ```latex \toks0={abcde} \def\mychars{abcde} ``` E fai così: ```latex \\uppercase\\expandafter{\\mychars} \\uppercase\\expandafter{\\the\\toks0} ``` in entrambi i casi ora vedrai composto ABCDE perché il `\\expandafter` causa il “disimballaggio” (espansione) di `\mychars` e `\\the\\toks0`—entrambi portano a `\uppercase` vedere un flusso di token di carattere, che possono elaborare per cambiare il maiuscolo/minuscolo. ### Esempio 2: \\\string—altre liste di token temporanee Internamente, TeX classifica `\string` come uno dei suoi cosiddetti comandi “convert”: eseguendo l'operazione di “convertire in testo”. Il `\string` comando è progettato per convertire un token in una versione testuale leggibile dall'uomo—cioè, comporre la stringa di caratteri leggibile dall'uomo da cui quel token è stato originariamente creato. Ad esempio `\\string\\hello` crea un elenco temporaneo di token che contiene i caratteri \\, h, e, l, l, o — sì, includendo persino il ‘\\\’ iniziale. Una volta creato quell'elenco di token, esso viene quindi riletto da TeX e il testo del comando “`\\hello`” viene composto—sì, includendo ‘\\\’ se scegli il font corretto… Potresti chiederti come/perché TeX possa comporre il carattere di escape quando di solito viene usato per indurre lo scanner di TeX a creare un token di comando: perché qui non lo fa? La risposta ha a che fare con i codici di categoria: di solito un carattere ‘\\\’ ha catcode 0 (carattere di escape) ma quando `\string` genera il proprio elenco di token interno fa qualcosa di un po' diverso. Quando crea un elenco di token di caratteri assegna il codice di categoria 12 a tutti i caratteri tranne il carattere spazio, a cui viene assegnato il catcode 10—ricorda che i token di carattere sono calcolati come 256 x catcode + valore ASCII. Quindi, quando TeX rilegge (inserisce) l'elenco temporaneo di token che `\string` generato da `\\hello`, *non vede un carattere di escape* perché il token per ‘\\\’ è stato calcolato con un catcode 12 e non 0: TeX tratta semplicemente ‘\\\’ come un carattere normale e lo compone. A rigor di termini, dovremmo probabilmente notare che TeX non genera realmente un token per i caratteri di escape quando li rileva nell'input. Una volta riconosciuto un carattere con codice di categoria 0, quel carattere viene semplicemente usato per “attivare” la generazione di un token di sequenza di controllo: una volta che ha attivato TeX a farlo, il carattere di escape ha svolto il suo compito e non viene più considerato. ### Nota tecnica Un comando chiamato `\\showtokens{...}` (introdotto dal motore e-TeX) può mostrare elenchi di token (nel file di log). Dal manuale di e-TeX: > Il comando `\\showtokens{}` visualizza l'elenco di token e consente di visualizzare quantità che non possono essere visualizzate da `\\show` o `\\showthe`, ad es.: > > ```latex > \\showtokens\\expandafter{\\jobname} > ``` ## In conclusione Nella sezione 291 del codice sorgente di TeX (vedi pagina 122 di [TeX: The Program](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373)) Knuth descrive un elenco di token come segue: > “Un elenco di token è una lista a collegamento singolo di nodi di una parola in mem, in cui ogni parola contiene un token e un collegamento. Le definizioni di macro, le definizioni della routine di output, i mark, `\\write` i testi di \\\write e poche altre cose vengono memorizzati da TeX sotto forma di elenchi di token, di solito preceduti da un nodo con un conteggio di riferimenti nel suo campo “token\_ref\_count”.” A una prima lettura potrebbe non essere stato facile da capire, ma, si spera, ora possa avere un po' più di senso. --- # 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/it/articoli-approfonditi/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.