Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Should the parser stay ANTLR-generated? (intent of #565, needs-design)

Abierto
  • ¿Algo no está bien?
#898 4 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Refactorización
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
csharp
Área
compilers

Línea de trabajo

Empieza leyendo Core/Antlr, AngouriMath.g, Docs/Contributing/ImproveParser.md y StringizeRoundTripTest para comprender el parser actual y sus criterios de aceptación. Cualquier reemplazo propuesto debe evaluarse en cuanto a la preservación round-trip, los mensajes de error, el coste de ejecución y si Docs/Usage/Syntax.md sigue siendo preciso; el issue estará terminado cuando los maintainers hayan tomado una decisión respaldada por esas comprobaciones.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Splitting the intent of #565 out of the branch, which is being closed: it proposed replacing the ANTLR-generated parser with one built on Yoakke, and the question it raises is live even though the branch is not.

What the branch did

Deleted the whole of Core/Antlr — the grammar, the four generated files, the .interp/.tokens
artefacts and the bundled antlr-4.8-complete.jar — and replaced it with a hand-assembled parser:
+740 / −7185 across 26 files.

Why ANTLR is worth replacing

Not on parser-theory grounds. On the day-to-day cost of it:

  • The generated files are committed, so a grammar change is a two-step ritual — edit
    AngouriMath.g, run antlr_rerun.bat, then run a post-processing pass whose only job is to rewrite
    public to internal on the generated classes. Docs/Contributing/ImproveParser.md documents it,
    and the documentation has to warn you to regenerate the unmodified grammar first and check the diff
    is empty, so that a toolchain version difference is not mistaken for your change.
  • It needs a JDK to change the grammar at all, in a repository that otherwise needs only the .NET
    SDK.
  • A 1 MB jar is in the source tree.
  • The error messages are ANTLR's, which is why MissingOperatorParseException and friends exist to
    translate them, and why Docs/Usage/Syntax.md had to be written by hand as a separate statement of
    what the parser accepts.

Why it is not obviously worth doing

  • The parser works, and its contract is now tested. StringizeRoundTripTest holds printing to being
    parsing's inverse across every node type, and 2.0 fixed several node shapes that did not round-trip.
    A rewrite starts that guarantee from zero.
  • The grammar is the specification. Syntax.md describes it, but AngouriMath.g is the thing that
    decides, and it is 480-odd lines of readable declarative rules. A hand-written recursive-descent
    parser is more code and less obviously equivalent to a reader.
  • Yoakke is itself a dependency, and a small one — it would be trading a build-time dependency on a
    jar for a run-time dependency on a young library, which for a package with 313k downloads is a
    different kind of risk rather than less risk.
  • Nothing about the parser is currently a bug. The open parse issues are about what the grammar
    says — precedence, notation — not about how it is produced.

What would make this decidable

  1. Is the round trip preserved? StringizeRoundTripTest over every node type is the acceptance, and
    it did not exist when #565 was written.
  2. Are the error messages better? The reason to hand-write a parser is control over failure; if the
    replacement's messages are no better than the translated ANTLR ones, the main benefit is only the
    build simplification.
  3. What does it cost at run time? Parsing is on the hot path for FromString, which caches by
    string precisely because it is not free.
  4. Does Syntax.md stay true, and can it be generated from the new parser rather than maintained
    beside it?

I have no recommendation. The four costs above are real and so are the four objections, and this is a
maintainer's call about what the library wants to own. Filed so that the reasoning survives the branch
rather than being rediscovered in another four years.

Lenguaje dominante
C#
Estrellas
831
Forks
79
Merge medio
2 h 22 min
PR fusionados (30 d)
507

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ASC-Community/AngouriMath

Todos los issues de ASC-Community/AngouriMath

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.