bx::Scanner: cómo escribir parsers sin complicarse

Parsers don't have to be complicated

bx::Scanner: cómo escribir parsers sin complicarse

En este artículo, el autor de bgfx y bx explica por qué abandonó el generador de parsers Lemon y las soluciones ad hoc, y presenta bx::Scanner, una pequeña biblioteca de escaneo sin copias ni asignaciones. Con primitivas reutilizables como accept, acceptWhile y acceptUntil, y seguimiento integrado de líneas y columnas, permite escribir parsers simples y legibles. Se muestran ejemplos reales: lectura de líneas, parsing de INI, URLs, rutas de archivos y símbolos de stack traces. El resultado: menos dependencias, menos bugs y parsers que no tienen por qué ser complicados.

Los parsers realmente no tienen por qué ser complicados.
  1. imoverclocked

    Lo más difícil de escribir un parser es aceptar cognitivamente lo que se va a considerar entrada válida. Puedes hacer el mejor parser, rápido y bien especificado, pero invariablemente alguien lo (mal)usará de una manera inesperada.

    Ejemplos famosos: a pesar de tantas buenas intenciones iniciales, las etiquetas HTML no necesitan cerrarse, los números JSON se codifican demasiado a menudo como cadenas, YAML puede parecerse a lo que la mayoría espera o puede parecerse progresivamente más a JSON... y así sucesivamente.

  2. f311a

    Desafortunadamente, el análisis simple de URLs falla en muchas cosas. Hay una razón por la que cada biblioteca de análisis de URLs tiene al menos unos pocos miles de líneas de código.

    Una forma común de probarlo es simplemente pasar una URL IPv6: http://[f021:d981:b487:e57d:193e:550e::]/

  3. mrkeen

    Si dibujas una línea desde 'manipulación ad-hoc de bytes sin sentido' hasta 'combinadores de parsers', esto no puede estar más allá del 20% del camino.

    Mirando el parser de URL enlazado, ¿por qué no se ve así?

    url = do scheme

    authority

    path

    query

    fragment

    where

    scheme = ...

    authority = ...

    etc.

    Parece totalmente ad-hoc.

  4. Retr0id

    > LineReader divide la entrada en líneas, maneja \n y \r\n, y recorta el \r sobrante que a la entrada malformada le gusta dejar atrás

    ¿Hay una fuente común de \r extra en entradas malformadas, más allá de las que existen como parte de \r\n? ¿O es solo una pulla a los finales de línea estilo Windows? Si hay algo raro, creo que preferiría fallar ruidosamente.

    > Limitar el escáner interno a una sola línea hace que 'pasarse del final de una línea malformada' sea irrepresentable en lugar de meramente improbable.

    No veo realmente qué lo hace 'irrepresentable', y esto se lee más como 'si usaras la lógica de escaneo correcta, no podrías haber usado la lógica de escaneo incorrecta'.

  5. chrisjj

    Bien, pero

    > recorta el \r sobrante que a la entrada malformada le gusta dejar atrás

    ¿cómo distingue esto la variedad no sobrante?

Más de este día

2026-08-07