parsing - ¿Qué tecnología de análisis Haskell es más agradable de usar y por qué?
(3)
Hemos tenido un gran éxito al usar ''uu-parsinglib''; hemos pasado a Parsec, ya que es bastante más flexible y potente, por ejemplo, puede admitir el análisis lento si es necesario y no necesita usar explícitamente un combinador (como ''probar'' en Parsec) para marcar posibles puntos de retroceso.
Es cierto que en la actualidad necesita hacer un poco más del lado tokenizante de las cosas, pero para nosotros ese es un pequeño punto relativo a las fortalezas fundamentales de la biblioteca.
Significado "agradable", por ejemplo: puede escribir gramáticas de forma "natural" sin tener que reescribirlas de forma complicada, y sin tener que introducir un texto aburrido.
Estipulemos a los fines de esta pregunta que, a menos que el rendimiento de una tecnología sea patológicamente malo, el rendimiento no es el mayor problema aquí.
Aunque, una vez dicho esto, es posible que desee mencionar si una tecnología se cae cuando se trata de tener que reescribir una gramática por motivos de rendimiento.
Por favor, dame una idea del tamaño y la complejidad de las gramáticas con las que has trabajado, al responder a esta pregunta. Además, si ha utilizado alguna característica notable "avanzada" de la tecnología en cuestión, y cuáles han sido sus impresiones.
Por supuesto, la respuesta a esta pregunta puede depender del dominio, en cuyo caso, me gustaría saber este hecho.
Realmente depende de qué empiezas y qué quieres hacer. No hay una talla única para todos.
Si tienes una gramática LR (por ejemplo, estás trabajando con una gramática Yacc), es una gran cantidad de trabajo convertirla en una LL adecuada para Parsec o uu-parsinglib. Sin embargo, los muchos analizadores de sepBy etc. son muy útiles aquí, pero debes esperar que el analizador sea más lento que Happy + Alex.
Para el análisis del combinador de LL, uu-parsinglib y su predecesor uu-parsing son agradables, pero les falta algo como los módulos Token and Language de Parsec, por lo que quizás sean menos convenientes. Algunas personas les gusta el Parselib de Malcolm Wallace porque tienen un modelo diferente al de Parsec por retroceder pero no tengo experiencia de ellos.
Si está decodificando algún archivo formateado en lugar de algo así como un lenguaje de programación, Attoparsec o similar podría ser mejor que Parsec o uu-parsinglib. Mejor en este contexto es más rápido, no solo ByteString vs. Char, pero creo que Attoparsec hace menos trabajo con respecto al manejo de errores / seguimiento de ubicación de fuentes para que los analizadores sean más rápidos ya que están haciendo menos trabajo por elemento de entrada.
Además, tenga en cuenta que los formatos de archivo de texto pueden no tener siempre gramáticas como tales, por lo que es posible que deba definir algunos combinadores personalizados para realizar trucos léxicos especiales en lugar de simplemente definir "combinadores de analizador" para cada elemento.
Para el análisis de LR, encontré Frown de Ralf Hinze para ser más agradable que Happy: mejor soporte de errores y un formato más agradable para los archivos de gramática, pero Frown no se mantiene activamente y no está en Hackage. Creo que es LR (k) en lugar de LR (1) lo que significa que es más poderoso que el futuro.
El rendimiento no es realmente una gran preocupación por la gramática. Los lenguajes de programación tienen gramáticas complejas, pero puede esperar archivos bastante pequeños. En cuanto a los formatos de archivos de datos, realmente le corresponde al diseñador del formato diseñarlos de tal forma que permitan un análisis eficiente. Para los analizadores combinatorios no debería necesitar muchas características avanzadas para un archivo de formato de datos; si lo hace, el formato está mal diseñado (esto a veces sucede desafortunadamente) o su analizador sí lo está.
Para el registro, he escrito un analizador C con Frown, lenguaje sombreado GL con Happy, un analizador C sin terminar con UU_Parsing, y muchas cosas con Parsec. La elección para mí fue con lo que comencé, Gramática LR - Fruncir el ceño o Feliz (ahora Feliz como Fruncir el ceño no se mantiene), de lo contrario usualmente Parsec (como dije uu_parse es agradable pero carece de la conveniencia de LanguageDef). En el caso de los formatos binarios, hago mi propia versión, pero generalmente tengo requisitos especiales.
Recientemente, reformulé un analizador DSL en uu-parsinglib que había sido escrito en parsec. Descubrí que simplificaba mucho el programa. Mi principal motivación fue obtener el aspecto de autocorrección. Eso solo funciona. ¡Es prácticamente gratis! Además, preferí escribir mi analizador sintáctico en un estilo aplicativo en comparación con el estilo monárquico de Parsec.