Quantcast

Error detection in GLR Happy grammar

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Error detection in GLR Happy grammar

Ivan Perez
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?
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Error detection in GLR Happy grammar

P.C.Callaghan

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.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Error detection in GLR Happy grammar

Ivan Perez
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.
>
>  


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Loading...