[antlr-interest] Problems with semantic predicates

Haralambi Haralambiev hharalambiev at gmail.com
Fri Apr 18 09:09:37 PDT 2008


Jim,

Thanks a lot for the input.

I suppose I have not built the proper grammar, but as the project I am
currently working on was a "proof of concept", the backtracking option was a
reasonable one. Once the concept is accepted, I think either a great rework,
or a pure start from the beginning will be executed.

I have not dug that deep into ANTLR, but I am eager to do so; thus, I will
try to remove the backtracking option.

However, I think that I might not be able to do so, as the expressions in
the language I am working allows countless things, thus my "expression" rule
usually generates conflicts.

Regarding your comment for rewrite construct - in my case it's something
like this:

r2:
expr -> {hasArgExpr}? ^(EQ ($r::argExprTree) expr)
       -> expr

I.e. the construction
of rule r2 is deep within some rule r, which may or may not have an
argument expression. And I need that the rule r2 take into account
this and constructs the proper tree. Maybe it is a design flaw, I
don't know. I will review it, once I have time.

Once again, thanks, and have a nice weekend!

Hari

On 4/18/08, Jim Idle <jimi at temporal-wave.com> wrote:
>
> Hari,
>
>
>
> I think that you probably need to step back from the specific thing you
> are trying to do here and rework the grammar without backtracking. The
> backtracking option is a good thing for prototyping or when the thing you
> are going to parser doesn't particularly require speed, but if you use it
> without regard to the grammar construction you will usually end up in
> trouble. This is because it masks poor grammar construction, which, if you
> built up the grammar one 'rule' at a time would become more obvious.
>
>
>
> If you are getting syntax errors with conditional rewrites, then there
> must be something else wrong in there first I suspect. Additionally, I am
> having trouble seeing why you would 'need' to rewrite the same construct in
> two different tree shapes. Beware constructing a tree that 'looks' good, as
> though it isn't  bad way to think through your tree construction, it can
> make you forget that what you want is an efficient tree structure that has
> no ambiguities when parsing it. Perhaps you just always need ^(NODE xxx)?
>
>
>
> You may be reluctant to restart your grammar as you feel you have put a
> lot of work in to it, but if you start with a blank slate and no
> backtracking, you will be able to borrow from your original grammar and get
> a cleaner, faster grammar that won't cause you maintenance headaches.
> Otherwise, it looks like you will be spending a lot of time on the 'last
> 10%' of this grammar. Once you forgo backtracking you will find that
> generally things like this will actually be easier, not more difficult.
>
>
>
> Jim
>
>
>
> *From:* antlr-interest-bounces at antlr.org [mailto:
> antlr-interest-bounces at antlr.org] *On Behalf Of *Haralambi Haralambiev
> *Sent:* Friday, April 18, 2008 5:12 AM
> *To:* Johannes Luber
> *Cc:* antlr-interest at antlr.org
> *Subject:* Re: [antlr-interest] Problems with semantic predicates
>
>
>
> Hello,
>
> Is there a way to lure Ter's interest to answer whether this braces (sorry
> for the mistake ;-) ) functionality is in place?
>
> I am using the latest version, 3.0.1, that is downloadable from the site,
> so I guess it's not implemented :-(
>
> Hari
>
> On 4/18/08, *Johannes Luber* <jaluber at gmx.de> wrote:
>
> Haralambi Haralambiev schrieb:
>
> Hi Johannes,
>
> I don't understand what's the benefit of the two brackets.
>
> When I write {{$r::flag = false;}} the code that ANTLR produces is
> "{((r_scope)r_stack.peek()).flag = false;}", i.e. the brackets are added
> also, but they are still in "if (backtracking == 0)" statement, which is the
> check I want to skip somehow.
>
> Hari
>
>
> The two braces (brackets are "[]") should be the syntax which enables an
> action to be executed always, even during backtracking. But either you are
> using an too old version of ANTLR or Ter didn't implement this variant after
> all.
>
> Johannes
>
>
>
>
> On 4/17/08, *Johannes Luber* <jaluber at gmx.de <mailto:jaluber at gmx.de>>
> wrote:
>
>    Haralambi Haralambiev schrieb:
>
>        Hello Johannes,
>
>        So, if I understand correctly, you suggest to have the following
>        (using a scope):
>
>        r2
>        : {$r::flag}? Token1 -> ^(NODE Token1)
>        | Token1
>        ;
>
>        If the above is a correct assumption, then how can I set the
>        scope variable, as I could only think of the following way:
>
>        r
>        scope {
>         boolean flag;
>        }
>        : Token1^ Token2!
>           {$r::flag = true;}    r2
>        | Token1^
>         {$r::flag = false;}
>         r2
>        ;
>
>        This solution, however, will fail, as the action for setting the
>        scope variable will not be executed until the backtracking is
>        over. But I need this variable set, as it will be used as a
>        predicate for the parsing. Thus, we have a catch-22 situation.
>
>        A solution I could think of is not to have two alternatives for
>        r2, but rather construct the CommonTree manually with java code
>        and within to use the knowledge of the boolean flag. But I
>        dislike this solution and am open to suggestions.
>
>
>    Try using {{$r::flag = true;}}.
>
>    Johannes
>
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.524 / Virus Database: 269.23.1/1384 - Release Date: 4/17/2008
> 3:47 PM
>
> No virus found in this outgoing message.
> Checked by AVG.
> Version: 7.5.524 / Virus Database: 269.23.1/1384 - Release Date: 4/17/2008
> 3:47 PM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20080418/1ee541ac/attachment.html 


More information about the antlr-interest mailing list