Back to flin
flin

Construyendo un analizador léxico desde cero en Rust

Cómo construimos el analizador léxico de FLIN en Rust: del flujo de caracteres a tokens, reconocimiento de palabras clave y escaneo en modo vista.

Juste A. Gnimavo (Thales) & Claude | March 26, 2026 2 min flin
EN/ FR/ ES
flinrust

Un analizador léxico es lo primero que encuentra tu código. Convierte caracteres en significado. Antes de que un parser pueda entender la estructura de tu programa, antes de que un verificador de tipos pueda validar su corrección, antes de que un generador de código pueda emitir bytecode -- el analizador léxico debe leer tu archivo fuente un carácter a la vez y producir un flujo de tokens. Es la fase más humilde de un compilador, y posiblemente la más importante.

El analizador léxico de FLIN tiene un desafío inusual: debe manejar dos modos sintácticos fundamentalmente diferentes en el mismo archivo fuente. Los programas FLIN contienen código imperativo -- declaraciones de variables, flujo de control, llamadas a funciones -- intercalado con declaraciones de vista similares a HTML. El lexer debe cambiar entre estos modos sin perder su posición, sin identificar erróneamente tokens ni confundir un operador menor-que con una etiqueta HTML de apertura.

El escáner trimodal

rustpub struct Lexer<'a> {
    source: &'a str,
    chars: Peekable<CharIndices<'a>>,
    line: u32,
    column: u32,
    start: u32,
    mode: LexerMode,
}

#[derive(Debug, Clone, Copy, PartialEq)]
enum LexerMode {
    Code,           // Código normal
    View,           // Dentro de etiquetas HTML
    ViewExpression, // Dentro de {expresión} en vista
}

El modo Code es el predeterminado. Los tokens son operadores, palabras clave, identificadores y literales.

El modo View se activa cuando el lexer encuentra un < seguido de un carácter alfabético. En modo vista, el lexer emite tokens TagOpen, TagName, AttrName, TagClose, TagSelfClose y TagEnd.

El modo ViewExpression se activa cuando el lexer encuentra { mientras está en modo vista. Dentro de las llaves, el lexer revierte a tokenización en modo código.

Al final de la sesión 4, el lexer tenía 97 pruebas unitarias. Cuando empezamos a construir el parser en la sesión 5, el flujo de tokens era confiable. Nunca tuvimos que depurar un error del parser que resultara ser un error del lexer. Ese es el retorno de inversión de las pruebas exhaustivas del lexer.


Esta es la Parte 12 de la serie "Cómo construimos FLIN".

Share this article:

Responses

Write a response
0/2000
Loading responses...

Related Articles

Thales & Claude deblo

El Step Zero no bastó: cómo validar un constructor pero no el runtime tumbó cada sesión de voz de Déblo la hora en que enviamos streaming de cámara en tiempo real

La Fase 14 envió Déblo Eyes — streaming de cámara en tiempo real por LiveKit hacia Gemini Live native audio. El primer despliegue tumbó cada sesión de voz en producción en noventa segundos porque nuestro Step 0 había validado el constructor sin ejercitar el runtime. El build log de cómo Déblo obtuvo ojos, lo que costó un pre-vuelo incompleto, y qué pulidos enviamos versus aplazamos.

33 min May 20, 2026
debloclaude-opus-4.7claude-codegemini-live +25
Thales & Claude deblo

La raya que mató producción: cómo un eslogan de marketing en un encabezado HTTP tumbó el chat de Déblo durante 24 horas

Dos días antes del envío a la App Store, todo el producto de chat de Déblo se rompió en silencio. Sin spinner, sin toast, sin error en la UI — solo aire muerto. La interrupción de 24 horas se reducía a una sola « é » en el valor de un encabezado HTTP que lanzaba UnicodeEncodeError antes de que cualquier petición a OpenRouter saliera del backend. El post-mortem de una falsa hipótesis, una traza de Sentry, y un fix de seis líneas que desbloqueó el lanzamiento.

29 min May 19, 2026
debloclaude-opus-4.7claude-codeincident +19
Thales & Claude deblo

Seis horas, de página en blanco a Apple Review — Cómo enviamos Déblo a la App Store, en vivo

Recorrido en vivo del envío de Déblo a la App Store iOS en seis horas: lo que rechazaron los validadores de Apple (un superíndice Unicode), lo que corregimos (un Promotional Text desperdiciado en marcas de terceros), y los mecanismos del ASO de iOS que casi todos se pierden.

30 min May 13, 2026
debloclaude-opus-4.7claude-codeapp-store +16