[antlr-interest] context information through rule parameters

Thomas Brandon tbrandonau at gmail.com
Fri Jul 4 01:38:39 PDT 2008


On Fri, Jul 4, 2008 at 5:53 PM, Gerard van de Glind
<g.vandeglind at beinformed.nl> wrote:
> Hi Gavin and all,
>
> Thanks Gavin for your reply!
>
> At 20:04 3/07/2008, Gerard van de Glind wrote:
>  >Because of this, my grammar contains two rules that use
>  >backtracking. This also implies that it is impossible to
>  >replace these by syntactic predicates.
>
> You're mistaken about that -- all backtracking does is to insert
> automatic syntactic predicates, so anything you can do with
> backtracking you can do by writing your own synpreds.
>
> Yes, you are right about that. I know that backtracking inserts
> syntactic predicates under the hood. But is this the only thing it does?
> I have seen that ANTLR also generates the following statement: if (
> backtracking==0 ) So is the behavior of ANTLR with the backtrack option
> compared to ANTLR with my own syntactic predicates really the same? And
> is it always possible to replace the backtrack option with my own
> syntactic predicates in such a way that it accepts the same language?
>
The backtracking==0 just means is the grammar in guessing mode while
processing syntactic predicates. It is not specific to grammars with
backtracking=true. It is always possible to duplicate the results of
backtracking with manual syntactic predicates.
> It might just be more work than what you want to do :)
>
> Please explain, can you give me a hint of what I should do? Sofar, I
> didn't succeed in being able to make my grammar to accept the same
> language with my own syntactic predicates compared to the backtrack
> option.
You may be able to look at the code generated with backtracking and
get ideas from there. I think that it should only insert predicates
where necessary and should have comments for them. Though I might be
wrong in those assumptions. Otherwise I'm not too sure of any
particular hints. One trick is to try and make sure you identify the
root cause of an ambiguity. Often an ambiguity will flow on and
produce further ambiguities in higher-level rules, you want to
identify and solve the lowest level problems. But based on your
example I think you may need to rethink your approach.
>
> The grammar I presented is over simplified...in the original grammar I
> also use actions and interrule communication through parameter passing.
> I just learnt that it is possible to run into a situation where method
> arguments result in noncompilable code if you use backtracking and
> parameter passing a lot (paragraph 14.7 of The Definitive ANTLR
> Reference). A solution to this problem is to use dynamic scopes.
>
>  >      relationalExpression[boolean checkAmbiguity]
>  >        options {backtrack=true;}
>  >              :       formula[true]   (LET^ | GET^ | LT^ | GT^)
>  >formula[true]
>  >              |       dateAtom[true]  (LET^ | GET^ | LT^ | GT^)
>  >dateAtom[true]
>  >              |       booleanAtom[$checkAmbiguity]
>  >              ;
>  >
>  >      formula[boolean bool]
>  >              : IDENTIFIER;
>  >
>  >      dateAtom[boolean bool]
>  >              : IDENTIFIER;
>
> Even backtracking isn't going to help you disambiguate those first
> two alts of relationalExpression -- they're exactly identical.
>
> I am aware of the fact that my grammar is ambiguous, but that's
> something I have to live with.
> I don't want to resolve the ambiguity, I want to recognize it and give a
> warning to the end users.
What is the purpose of seperate rules for formula and dateAtom? They
both match the same thing, how are they suppossed to be useful? Surely
they should be rolled into a single alternative. While semantically
distinct, these are syntactically identical, there is no way to deal
with them seperately at this point. You may be able to use semantic
information (e.g. declared types) to resolve the ambiguity in a later
stage but your current approach just isn't right.

Tom.
>
> Thanks again!
>
> Cheers, Gerard
>


More information about the antlr-interest mailing list