Ik ben “The Definitive Antlr 4-referentie” aan het lezen en krijg een idee van hoe luisteraars en bezoekers werken. Het boek legt bijzonder goed uit hoe luisteraars zich verhouden tot SAX-parsers en maakt duidelijk wanneer methoden worden aangeroepen tijdens de implementatie van elk. Ik kan ook zien dat luisteraars redelijk goed zijn in het omzetten van input naar output, maar ik zou een korte uitleg/voorbeeld op prijs stellen over wanneer een luisteraar en wanneer een bezoeker moet worden gebruikt (of moeten ze beide in bepaalde gevallen worden gebruikt?).
Mijn specifieke bedoeling is om een tolk te maken (Cucumber-stijl / TinyBasic Interpreter met enkele aangepaste aanroepen) die zal controleren op syntaxisfouten en zal stoppen met het uitvoeren van een fout van een aangepaste functie zonder te herstellen – zou graag een volledige implementatie zien van zoiets in antlr – als iemand er toevallig een weet.
Bij voorbaat dank voor elk advies.
Antwoord 1, autoriteit 100%
Hier is een citaat uit het boek dat volgens mij relevant is:
Het grootste verschil tussen de luisteraar- en bezoekersmechanismen is dat listenermethoden worden aangeroepen door het door ANTLR geleverde walker-object, terwijl bezoekersmethoden hun kinderen moeten begeleiden met expliciete bezoekoproepen. Vergeten bezoek() aan te roepen op de onderliggende elementen van een knooppunt betekent dat die substructuren niet worden bezocht.
In bezoekerspatroon heb je de mogelijkheid om bomen te laten lopen terwijl je in luisteraar alleen reageert op de bomenloper.
Antwoord 2, autoriteit 72%
Als u van plan bent de uitvoer van de parser rechtstreeks te gebruiken voor interpretatie, is de bezoeker een goede keuze. Je hebt volledige controle over de traversal, dus in conditionals wordt slechts één tak bezocht, loops kunnen n keer worden bezocht, enzovoort.
Als u de invoer naar een lager niveau vertaalt, b.v. instructies voor virtuele machines, beide patronen kunnen nuttig zijn.
Je zou eens kunnen kijken naar “Taalimplementatiepatronen”, die de basisimplementaties van tolken omvat.
Ik gebruik meestal het bezoekerspatroon, omdat het flexibeler is.
Antwoord 3, autoriteit 32%
Er is nog een belangrijk verschil tussen deze twee patronen: een bezoeker gebruikt de call-stackom tree traversals te beheren, terwijl de luisteraar een expliciete stackgebruikt die op de heap is toegewezen, beheerd door een wandelaar. Dit betekent dat grote input voor een bezoeker de stapel zou kunnen wegblazen, terwijl een luisteraar geen problemen zou hebben.
Als uw invoer mogelijk onbegrensd zou kunnen zijn, of als u uw bezoeker erg diep in een gespreksboom zou kunnen noemen, moet u een Luisteraar gebruiken in plaats van een Bezoeker, of in ieder geval valideren dat de ontledingsboom niet te diep is. De coderingspraktijken van sommige bedrijven ontmoedigen of verbieden om deze reden zelfs ronduit non-tail recursie.
Antwoord 4, autoriteit 2%
Uit het boek, pagina 120.
Bezoekers werken heel goed als we toepassingsspecifieke retourwaarden nodig hebben, omdat we het ingebouwde Java-retourwaardemechanisme kunnen gebruiken. Als we liever niet expliciet bezoekersmethoden hoeven aan te roepen om kinderen te bezoeken, kunnen we overstappen op het luisteraarmechanisme. Helaas betekent dat het opgeven van de netheid van het gebruik van Java-methode-retourwaarden.
Daarom gebruik ik bezoekers.