Attempting full context
Jochen Wiedmann
Hi,
My parser has an error listener, on which the method reportAttemptingFullContext is invoked. I believe to have understood, what this warning indicates (in particular, that it seems to be caused by the lexer rules).
However, I don't know how to use the supplied parameters (startIndex=9, stopIndex=9, conflictingAlts, and configs) to find the offending rule(s), or input. Can anyone help, please?
Thanks,
Jochen
Sam Harwell
Hi Jochen,
The ANTLR 4 lexer always executes with full context, so it wouldn’t produce a warning like that.
Do you have a copy of the parser and input I can experiment with? ANTLRWorks 2.2 has a new feature that may be able to diagnose your issue in detail; I’d be curious to experiment prior to the release.
Thanks,
Sam
--
You received this message because you are subscribed to the Google Groups "antlr-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to antlr-discussi...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Terence Parr
Sam Harwell
It actually only means the decision might require more than SLL(*) parsing, so it’s using LL(*) to make sure. As long as the grammar isn’t ambiguous, then you’re correct that it’s only an efficiency warning.
The ANTLRWorks 2.2 parser interpreter analysis actually reports both this number and the number of true context sensitivities, which are decisions/inputs where SLL(*) alone would return an incorrect answer. In those cases, LL(*) is actually required for correctness.
Sam
Jochen Wiedmann
On Thursday, February 13, 2014 7:43:14 PM UTC+1, Sam Harwell wrote:
Do you have a copy of the parser and input I can experiment with? ANTLRWorks 2.2 has a new feature that may be able to diagnose your issue in detail; I’d be curious to experiment prior to the release.
I am not sure, whether this works, but have a look on
https://drive.google.com/folderview?id=0B5t2kUl4hdZrUXMzSmFQVHJFbTg&usp=sharing
I uploaded grammar (Ns3mod.g4) and sample input FIELDS.NS3
Jochen Wiedmann
On Thursday, February 13, 2014 7:43:14 PM UTC+1, Sam Harwell wrote:
Do you have a copy of the parser and input I can experiment with? ANTLRWorks 2.2 has a new feature that may be able to diagnose your issue in detail; I’d be curious to experiment prior to the release.
Is that available for download? I'd like to give it a shot.
Thanks,
Jochen
Sam Harwell
Hi Jochen,
First of all, yes it did work, and the results provided by ANTLRWorks are interesting.
One feature you can use even in ANTLRWorks 2.1 is the Lexer Interpreter (Run -> Interpret Lexer...). The controller window for the lexer is Window -> Lexer Debugger Controller. I direct you to line 254, which is the first line in the file which consists of multiple tokens on the same line. In the Lexer Debugger Controller window, if you select the Types tab and click PARAM_VALUE, you can see the several lines near the end of the file which consist of more than one token.
The next thing I did was launch the new ANTLRWorks 2.2 Interpret Parser... feature. Here is the result of the conflict analysis:
The columns are:
1. Decision: The decision number, assigned by ANTLR 4 when the parser is generated.
2. Rule: The name of the rule containing the decision.
3. Count: The number of times this decision was encountered while parsing the input.
4. Conflicts: The number of SLL conflicts that occurred. An SLL conflict occurs when ANTLR cannot determine if the rule is ambiguous or not, and must use the slower but more powerful LL prediction process to guarantee a correct decision is made. This situation produces the reportAttemptingFullContext warning, but it’s not a problem unless you have ambiguities or context sensitivities (keep reading).
5. Ambiguities: The number of times a decision was actually ambiguous, meaning two or more parse trees are possible starting from this decision, so ANTLR had to just pick [the first] one. These are important to understand, because if ANTLR chooses the wrong case then the resulting parse tree will not be an accurate representation of your input.
6. Context Sensitivities: The number of times the SLL prediction algorithm would have returned a wrong answer. If you have even one of these anywhere in your input, the two-stage parsing strategy will not improve performance because the context sensitivity guarantees that ANTLR will be forced to fall back to the second stage even if the input does not contain syntax errors. Context sensitivities are not the end of the world. In fact, ANTLR 4’s biggest contribution to parsing theory is its ability to handle these situations – ANTLR 3 and most backtracking LL(k)/LL(*) parsing algorithms are simply unable to handle these situations. However, when it’s possible to avoid them it’s a good idea to do so for performance reasons.
I would start by taking the following steps:
1. Add an explicit EOF symbol to the end of your dialog_source rule. In its current form, your parser isn’t parsing the entire file because it reaches a syntax error and stops early.
2. Address the syntax errors for this input.
3. Only after the above are resolved, reexamine the parser behavior for the input to determine if changes need to be made for performance.
All of the bugs currently open for ANTLRWorks 2.2 are based on my observations from this grammar and input. For that, I thank you for providing this excellent example.
https://github.com/sharwell/antlrworks2/issues?milestone=1&page=1&state=open
I also added this issue that I’m sure will be relevant for new users, but assigned it to milestone 2.2.1.
https://github.com/sharwell/antlrworks2/issues/29
Sam
From: antlr-di...@googlegroups.com [mailto:antlr-di...@googlegroups.com]
On Behalf Of Jochen Wiedmann
Sent: Friday, February 14, 2014 2:54 AM
To: antlr-di...@googlegroups.com
Subject: Re: [antlr-discussion] Attempting full context
--