Il programma lex traduce una serie di direttive (contenute nel file lexer.l) in frammenti di codice C, producendo una routine di riconoscimento lessicale yylex() (contenuta nel file lex.yy.c) in grado di identificare e restituire le singole "parole" che il linguaggio ammette. Dal punto di vista di lex, l'input non è altro che una sequenza non-strutturata di token (le nostre "parole", appunto); un flusso di numeri interi destinata ad assumere significato soltanto in sede di analisi logica, allorchè yacc chiamerà yylex() e combinerà insieme i vari token per formare "frasi" di senso compiuto. Naturalmente, lex è molto di più che un semplice scanner di token. Utilizzando speciali costrutti (che solo in parte saranno presi in considerazione in questo articolo), lex può prendere decisioni a riguardo dell'associatività e della precedenza degli operatori matematici. Può, inoltre, effettuare delle vere e proprie transizioni di stato, in maniera che le sue regole di riconoscimento possano adattarsi a particolari situazioni, realizzando dei mini-scanners autonomi e indipendenti. Per capirne l'utilità, basta pensare ai token che vanno verso un modem: i codici che vengono subito dopo il token AT non hanno lo stesso significato che altrove, per cui un simulatore lex potrebbe opportunamente effettuare una transizione nello "stato comandi". E' proprio necessario usare lex per scrivere i nostri scanner? Nei casi più semplici, no. E' sempre possibile scrivere un equivalente di yylex() mediante una serie di chiamate tipo scanf(), ma in generale (specialmente se devono essere identificati oggetti più complicati come numeri reali in formato esponenziale, stringe, matrici, etc.) l'uso di lex può semplificare notevolmente le cose, soprattutto se si tiene conto della riusabilità e della manutenibilità del nostro codice. Secondo me la filosofia più corretta è quella di scrivere scanner più elementari possibili, demandando la comprensione vera e propria del "testo" interamente a yacc, che ha tutte le carte in regola per riuscirci bene.