Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
#898 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Refactoring
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
compilers

Direzione di ricerca

Inizia leggendo Core/Antlr, AngouriMath.g, Docs/Contributing/ImproveParser.md e StringizeRoundTripTest per comprendere il parser attuale e i relativi criteri di accettazione. Qualsiasi sostituzione proposta deve essere valutata in base alla conservazione round-trip, ai messaggi di errore, al costo di esecuzione e al fatto che Docs/Usage/Syntax.md rimanga accurato; l'issue è conclusa quando i maintainer hanno preso una decisione supportata da queste verifiche.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
C#
Stelle
831
Fork
79
Merge medio
2h 22m
PR unite (30g)
507

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ASC-Community/AngouriMath

Tutte le issue di ASC-Community/AngouriMath

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.