Mejorando los mensajes de ANTLR DSL parse-error

Question

Estoy trabajando en un lenguaje específico de dominio (DSL) para los no programadores. Los no programadores cometen muchos errores gramaticales: escriben mal las palabras clave, no cierran los paréntesis, no terminan los bloques, etc.

Estoy usando ANTLR para generar mi analizador sintáctico; proporciona un mecanismo ingenioso para manejar RecognitionExceptions para mejorar el manejo de errores. Pero me resulta bastante difícil desarrollar un buen código de manejo de errores para mi DSL.

En este punto, estoy considerando formas de simplificar el lenguaje para facilitar el suministro de mensajes de error de alta calidad a los usuarios, pero no estoy seguro de cómo hacerlo. Creo que quiero reducir la ambigüedad de los errores de alguna manera, pero no estoy seguro de cómo implementar esa idea en una gramática.

¿De qué manera puedo simplificar mi lengua para mejorar los mensajes de error de análisis sintáctico para mis usuarios?

EDIT: Actualizado para aclarar que estoy interesado en formas de simplificar mi lenguaje, no solo en las sugerencias de manejo de errores de ANTLR en general. (aunque, gracias por aquellos!)

Answer 1

leí un artículo recientemente acerca de alguien que implementa un mecanismo de aprendizaje simple para su analizador. Básicamente, la idea es etiquetar los errores de análisis que ANTLR le proporciona con la causa real del error. Por ejemplo,

Error: No method "bar" for NilClass: foo

podrían ser etiquetados como:

Error: Tried to call "bar" on foo, but foo didn't have a value.

La idea en realidad procedían de un documento de 2003: Generating LR Syntax Error Messages from Examples. También se ha discutido en el blog research!rsc.

Answer 2

Es probable que golpeó la parte más difícil de usar un generador de análisis, en comparación con una mano rodó la gramática.

Desde mi experiencia, lo primero que debe hacer es asegurarse de seguir con precisión la información de línea y columna para que pueda indicar al usuario el lugar exacto donde el analizador cree que está el error.

Eso debería hacerse cargo de un 90% de los problemas para los usuarios, es decir, las comas que faltan o punto y coma al final de una línea.

Es el otro 10% es donde el problema es.

normalmente comienzan proporcionando un nombre significativo a mi gramática léxica y fichas usando la palabra clave paraphrase.

es decir

SEMI 
options {paraphrase="end of line terminator";} 
: ';' 
; 

ifExpr 
options {paraphrase="boolean expression";} 
    : expr 
; 

Antlr utilizará estas frases en cualquier mensaje de error que genera.

Para ver cómo los expertos recomiendan que lo hagas con Antlr 2 y luego mira esta página: http://www.antlr.org/blog/antlr3/error.handling.tml para ver los cambios que Antlr 3 ha hecho. (La página Antlr2 es probablemente el mejor lugar para comenzar).

Answer 3

Escribí un artículo sobre la recuperación de números de líneas y columnas en errores ANTLR hace un par de años que podría ser útil.

http://tech.puredanger.com/2007/02/01/recovering-line-and-column-numbers-in-your-antlr-ast/

Answer 4

bien, nunca he utilizado antlr hasta el momento, sólo se JavaCC. Pero como va a implementar una DSL y se preocupa por la usabilidad, debería echarle un vistazo al xtext. Es un marco que

• le permite especificar una gramática textual para su DSL en EBNF notación
• genera un analizador para usted
• genera un editor con resaltado de sintaxis y la retroalimentación inmediata sobre los errores sintácticos como un plugin de Eclipse
• le da acceso a la AST subyacente para transformar la representación textual que los usuarios crean en nada

asistí a una presentación de itemis el año pasado, una empresa alemana que se especializa en DSL. Estaba muy impresionado de lo fácil que es configurar esto y ponerme a trabajar. Lo usé para crear un editor para un pequeño juego que utiliza una descripción textual del campo de juego que luego se analiza y se transforma en el modelo de objetos del juego.