[antlr-interest] Predicate hoisting pain

Sam Barnett-Cormack s.barnett-cormack at lancaster.ac.uk
Mon Apr 13 06:35:27 PDT 2009


Sam Harwell wrote:
> This will fail unexpectedly with certain types of grammars, as
> demonstrated by some grammars I've sent to the list in the past. I'll
> find them later today and send a link.

I can't see why it'd fail horribly in this case... the problem would 
come if os were being used in a higher rule for something entirely 
different and the predicate got hoisted.

In this case, the predicates getting hoisted in just wasteful. It's 
checking loads of stuff unnecessarily, because it's going to call the 
rule the predicate is in in either case! I think the logic that needs 
fixing is examining the branches of the choice the predicate got hoisted 
into, and if it's hoisted into every branch drop it again. That would 
solve my issue at least, and I can't imagine a situation where it'd be 
dropped that it would cause a problem.

The other option is to detect predicates that use a parameter, and do 
some substitution in the hoist so that the parameter is substituted (as 
it's the calling rule that sets it). This might leave it with a 
parameter (of the "outer" rule) in use. However, if you do it repeatedly 
when hoisting through multiple layers, it'd work out in the end. As it 
is, if you have "stacked" rules like this passing a parameter, you may 
get inconsistent results depending on naming,

This makes me think that a scoped variable might be a better bet, but 
I'm not sure. I don't think I fully understand nesting of scopes.

Sam (BC)

> -----Original Message-----
> From: Sam Barnett-Cormack [mailto:s.barnett-cormack at lancaster.ac.uk] 
> Sent: Monday, April 13, 2009 7:55 AM
> To: Sam Harwell
> Cc: ANTLR Interest Mailing List
> Subject: Re: [antlr-interest] Predicate hoisting pain
> 
> Sam Barnett-Cormack wrote:
>> I guess the question really is, for me, why does it get hoisted in one
> 
>> case and not another? I'm assuming it's because of the choice in the 
>> objectSetSpec rule, and I can't see any way to refactor that to lose
> the 
>> choice. Of course, there's probably a kludgy solution of setting a 
>> variable os to true and passing it...
> 
> And that worked... changed it to:
> 
> objectSetSpec
> @init{
>    boolean os = true;
> }
>    : rootElementSetSpec[os] (COMMA EXTMARK
> additionalElementSetSpec[os]?)?
>    | EXTMARK (COMMA additionalElementSetSpec[os])?
>    ;
> 
> Horrible, but in some ways less horrible than the more "elegant"
> solutions.
> 
>>> -----Original Message----- From: antlr-interest-bounces at antlr.org 
>>> [mailto:antlr-interest-bounces at antlr.org] On Behalf Of Sam 
>>> Barnett-Cormack Sent: Monday, April 13, 2009 6:33 AM To: ANTLR
>>> Interest Mailing List Subject: [antlr-interest] Predicate hoisting
>>> pain
>>>
>>> Hi all,
>>>
>>> So, in my grammar I have need to re-use rules so they ultimately
>>> refer to a different rule (so I don't have to duplicate 
>>> intersection/union/exception rules). I use a parameter and gated 
>>> predicates, like so:
>>>
>>> elements[boolean os] : {!$os}?=>subtypeElements |
>>> {$os}?=>objectSetElements | LPAREN! elementSetSpec[$os] RPAREN! ;
>>>
>>> This is ultimately referred to from two places. The first, which 
>>> generates code that's just fine, is:
>>>
>>> elementSetSpecs : rootElementSetSpec[false] (COMMA EXTMARK (COMMA 
>>> additionalElementSetSpec[false])?)? -> ^(ELEMENTSET
>>> rootElementSetSpec EXTMARK? additionalElementSetSpec?) ;
>>>
>>> However, in the *slightly* more complex case:
>>>
>>> objectSetSpec : rootElementSetSpec[true] (COMMA EXTMARK 
>>> additionalElementSetSpec[true]?)? | EXTMARK (COMMA
>>> additionalElementSetSpec[true])? ;
>>>
>>> The predicates get hoisted in the generated code, and then there's 
>>> compile errors with undefined variable 'os'.
>>>
>>> I'm not sure why it happens in one case and not the other, and I'm
>>> even less clear on how to fix it. Can anyone help?
>>>
>>> Sam
>>>
>>> List: http://www.antlr.org/mailman/listinfo/antlr-interest 
>>> Unsubscribe: 
>>>
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>> List: http://www.antlr.org/mailman/listinfo/antlr-interest
>> Unsubscribe:
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
> 



More information about the antlr-interest mailing list