On Tue, 26 Apr 2022 at 02:00, Rk <[email protected]> wrote: > When does one use events or actions? > > Are there distinct use case where events gets used vs actions?
Marpa works in two phases: first the recognizer consumes the input. If this succeeds, we know that the input conforms to the grammar. Then, optionally, one or more syntax trees can be extracted from the traces left by the recognizer. Events are triggered during the recognizer phase. For example, we might get an event whenever a certain lexeme (token) is expected in the input. This can be used e.g. to plug in to the recognizer and read that lexeme ourselves, for example if we want to nest different languages or if we want to introduce context-sensitive features like here-docs. Another use case is error recovery, for example with the Ruby Slippers parsing strategy. But since events are triggered during the recognizer phase, they can be difficult to use correctly. There is no guarantee that the parse will succeed. Depending on the grammar, there might be unresolved ambiguity. Unless you know exactly what you are doing, event handling should be stateless. Actions are used during the evaluation phase when the syntax tree is built. Actions are evaluated bottom-up to build the tree. The actions describe what should be done with the values on the right hand side of a rule. It is not necessary that the actions actually create a syntax tree, they just have to produce some kind of value. For example, a calculator for arithmetic expressions might use actions to immediately evaluate the expression (as shown in the Marpa::R2 synposis <https://metacpan.org/dist/Marpa-R2/view/pod/Marpa_R2.pod#Synopsis>). > When I look at Marpa.pm from Graphviz, there are no actions declared as part of grammar.(apart from default). The Graphviz2::Marpa module takes a somewhat unusual strategy. It only produces a value to check that the parse was successful, but does not use the value to build its syntax tree. Instead, it uses an event-based approach to process the document. A good example of understanding event-driven parsing might be the SAX Parser <https://en.wikipedia.org/wiki/Simple_API_for_XML>, an XML parsing approach popular in a Java context. Normally, an XML parser would turn the XML document like “<document> text <element/> </document>” into a Document Object Model, essentially an abstract syntax tree. Instead, the SAX parser emits events as elements are opened/closed: element start “document”, text node “text”, self-closing element “element”, element end “document”. At first glance, it seems unnecessarily complicated that the Graphviz module is using such an approach. I would have tried to use actions instead, especially since events can be quite tricky to use correctly. Maybe there was an unusual design constraint that I don't see – maybe Ron will chime in later. -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/marpa-parser/CAJTYOd1vJw7sk7Wdh3ai7d0v8REcU4r4n4CzeYvPsSHR1HBLNg%40mail.gmail.com.
