Parser Combinators : une introduction visuelle aux alternatives entre regex et parseurs
Sommaire
En bref
- Les parser combinators permettent de construire des parseurs complexes en composant des fonctions simples, idéaux quand regex devient trop limité mais qu'un parseur complet serait overkill.
- L'article propose une approche visuelle en slides avec animations, en TypeScript.
- Le format slideshow plaît pour l'animation mais crée des frictions UX : zone de contenu exiguë, impossibilité de rechercher, navigation malaisée.
Ce que dit la source
L'auteur pose le problème courant du parsing intermédiaire : regex est insuffisant pour les grammaires contextuelles (impossible de gérer la récursivité), tree-sitter et les parseurs générés sont trop lourds pour des cas simples. Les parser combinators offrent un équilibre : composer des parseurs élémentaires pour construire des parseurs complexes, le tout en code ordinaire (TypeScript ici).
- L'article repose sur une définition simple : type Parser<T> = (input: string) => [T, string] (parseur = fonction retournant la valeur extraite et le reste de la chaîne).
- Les combinateurs permettent de chaîner des parseurs élémentaires pour en construire de plus complexes, sans générer de code séparé.
- Le format en 17 slides avec animations rend intuitif le concept, particulièrement pour comprendre la composition progressive de parseurs.
- La source ne donne aucune métrique de performance ni comparaison directe avec d'autres approches (parser generators, bibliothèques existantes).
Dans les commentaires
Débat partagé : plusieurs commentateurs louent l'approche pédagogique et les animations, mais presque tous soulignent des défauts UX graves (format slideshow, zone de contenu réduite) qui nuisent à la clarté. Au-delà de la forme, quelques commentaires touchent à des limites conceptuelles (définition floue de « parser partiel », absence d'erreur handling visible).
- Plusieurs commentateurs critiquent le format slideshow : recherche impossible, zone de contenu exiguë, impossibilité de consulter plusieurs sections simultanément. Cela reproduit artificiellement les limites du papier en digital.
- Des objections conceptuelles : la distinction affichée entre « parser partiel » et « parser complet » n'existe pas réellement (toute composition de parseurs est partielle si chacun peut échouer). Le type retourné (T ou undefined ?) n'est pas explicité.
- Manque de gestion d'erreurs visible : aucun exemple ne montre comment signaler où et pourquoi le parsing a échoué, pourtant essentiel en pratique.
- Un commentateur note que l'exemple introductif parse 1.1.1.1 comme adresse IP, mais ignore que cela peut aussi être un hostname : occasion manquée de montrer comment combiner plusieurs alternatives.
- L'absence de documentation officielle sur re.Scanner en Python est signalée comme une solution écrasée par oubli, illustrant un besoin réel mais non comblé par les écosystèmes mainstream.
Alternatives citées : Plusieurs alternatives mentionnées ou implicites dans les commentaires : parser generators (grammaires déclaratives séparées), re.Scanner en Python, tree-sitter, iteratees (approche fonctionnelle avancée). Quelques commentateurs citent leurs propres bibliothèques expérimentales (marser en Rust, unitas en TypeScript).
Notre lecture
Synthèse pédagogique utile pour comprendre l'idée centrale des parser combinators, jamais très visible hors des cours de langage fonctionnel. Les animations aident. Mais l'article reste introductif et esquive les vrais défis pratiques : gestion d'erreurs fine, performance, emboîtement correct des parseurs (ordre important). Utile pour les équipes qui implémentent un langage, DSL ou interpréteur simple ; peu pertinent comme recommandation générique. À surveiller si l'auteur publie une suite sur erreurs et performance, mais le format actuel limite la transmission.