Re: LR(1) Parsing : Error Handling & Recovery

On 2014/07/19 23:40, Evangelos Drikos wrote:


> On 7/19/14, 4:29 PM, Hans Aberg wrote:
>> A GLR parser splits the parses in face of an ambiguity, which might be
>> used instead. Bison supports this, but currently the actions during a
>> parse split are not executed, and so cannot set context variables for
>> the lexer, until the merge.
>
> A GLR parser splits on conflicts and thus needs two different types of
> actions.


As for Bison, there have been discussions to admit this, but as far as
I know, it does not have it currently.


> I recall that DParser uses the terms speculative and final.


Or perhaps direct (immediate) and delayed, or something. Bison then only
has the delayed.


> In my GLR Builder I use the terms semantic checks & actions.
>
> Semantic checks are not delayed when the parser splits but they should
> not have side effects. In general, it is unsafe to notify the scanner
> that the parser has just reached a particular state.


The lexer probably need some extensions as well. May be useful for
parsing natural languages.


> In contrast, you can query a symbol table to reject an active parser or
> just create a node for the AST of the current parse. BTW, its my
> impression that Elkhound and Elsa parse C++ with actions that actually
> are immediate; but i have not read their code to be sure.


It is possible to make a LALR(1) parser for C++: one parses a larger
language, and cuts it down in the actions.


> To conclude, in a deterministic LALR parser semantic actions are both
> immediate and final but in a GLR parser this principle doesn't hold.


Right. Only for simultaneous, parallel parses, if some reader here wonders.

Return to the comp.compilers page.
Search the comp.compilers archives again.