Error detection in GLR Happy grammar
Hi! I'm trying to detect parse errors in a happy GLR grammar, but I can't! I insert the special "token" 'error', and call the error function when an error is found. However, the program prints no error messages, and simply returns a ParseError at the end. Does any of you have an good example of a GLR parser with error detection and, if possible, error recovery as well?
Hello, "error" isn't implemented yet in GLR mode - it is ignored. Note that yacc-style error handling can't be transplanted directly into GLR, since the nature of parse errors is not the same. In LR(k) errors mean that the single parse can't continue and hence some remedial action is needed. In GLR, it could mean this (when following one unique parse), or with multiple parses that some are being dropped because further input has ruled them out. Recovery on the latter probably isn't correct - they should be discarded. I might try allowing an explicit error token which acts only when one parse is live, and follow standard Happy behaviour for this. If you have an example to test on, it might be useful. Note that for failed parses, you are given a list of unconsumed tokens and the partial parses constructed so far, so some diagnosis is possible. Paul ps. I've almost fixed the module header problem you mentioned before.
P.C.Callaghan wrote:
Hello,
"error" isn't implemented yet in GLR mode - it is ignored.
Note that yacc-style error handling can't be transplanted directly into GLR, since the nature of parse errors is not the same. In LR(k) errors mean that the single parse can't continue and hence some remedial action is needed. In GLR, it could mean this (when following one unique parse), or with multiple parses that some are being dropped because further input has ruled them out. Recovery on the latter probably isn't correct - they should be discarded.
As far as I understand, if you don't do any IO actions, like printing error messages as soon as an "error" found (which could not be so, since the GLR parsing will end OK if at least a complete parsing tree is found) a proper result could be returned and everything should go fine.
I might try allowing an explicit error token which acts only when one parse is live, and follow standard Happy behaviour for this. If you have an example to test on, it might be useful.
I have a big grammar that might be great for this. However, I haven't specified the error recovery points in the productions yet, since I couldn't generate an LR parser with no conflicts. In fact, I tried solving these conflicts, but I found that the information Happy gives me about them is not informative enough: I couldn't even understand why some conflicts took place at specific positions.
Note that for failed parses, you are given a list of unconsumed tokens and the partial parses constructed so far, so some diagnosis is possible.
At this moment, our parser prints an error in the form of "line:column:error: Unexpected token 'TokenType'". The main problem here is that I don't want my compiler to stop as soon as a parsing error is found, but to recover from it and report all the errors at the end. I tried encapsulating the real return status of the parsing in a monad, so I can later know if the parsing was really OK or the ParseOK result I'm given is the result of recovering from an error. Then I realized I couldn't detect parsing errors like in LR and stopped doing this : (
Paul
ps. I've almost fixed the module header problem you mentioned before.
participants (2)
-
Iván Pérez Domínguez -
P.C.Callaghan