[antlr-interest] Actions in predicates

[Daniels, Troy (US SSA)]

So

Super; [TYPE] method

Should resolve as (1) followed by 3, but

Super [TYPE] method

Should resolve as (2)?

I think you probably want to include the semicolons in your default token stream.  You would then have rules like

type_method : TYPE METHOD SEMI? ;

super : SUPER ( SEMI | type_method | /* nothing */ ) ;

You could even rewrite super in the standard style for this grammar:

super : SUPER type_method_base? SEMI? ; 

type_method : type_method_base SEMI? ;

type_method_base : TYPE METHOD ;


It seems that would also be a more straightforward representation of the grammar.  Even if you can get the channel switching to work, will you remember why you are doing it six months from now?  Will you still understand the corner cases?  Even if you do, what about the guy who works on this after you?  What I outlined fairly clearly says "semi colons are optional" and makes it clear that "super ; [TYPE] ..." is two statements.

Troy


> -----Original Message-----
> From: antlr-interest-bounces at antlr.org 
> [mailto:antlr-interest-bounces at antlr.org] On Behalf Of Marcin 
> Rzeznicki
> Sent: Monday, February 22, 2010 1:39 PM
> To: Jim Idle
> Cc: antlr-interest at antlr.org
> Subject: Re: [antlr-interest] Actions in predicates
> 
> 2010/2/22 Marcin Rzeźnicki <marcin.rzeznicki at gmail.com>
> 
> >
> >
> > On Mon, Feb 22, 2010 at 6:21 PM, Jim Idle 
> <jimi at temporal-wave.com> wrote:
> >
> >> It's not completely flawed. To do what you asked, you do 
> not need to 
> >> influence the lexer, just look ahead in the off-channel at certain 
> >> points and change the channel of the SEMI back to the 
> default if you 
> >> wanted it to appear; but as I said, that is an awkward way 
> to do it I think.
> >>
> >> Jim
> >>
> >>
> >
> > My ideas was more or less that whenever I have ambigous 
> syntax (with 
> > no semicolons whatsoever in the parser)  I resolve problems using 
> > syntactic predicates  taking "optional" parts of syntax (like 
> > semicolons) into consideration. If syntactic predicate hit the 
> > optional part then it would fail - meaning that separator divided 
> > potentially ambigous construct and it is time to try the next 
> > alternative. It seemed clean to me, but you've made me 
> think about it 
> > again. I could use your suggestion to make semicolon tokens 
> reappear 
> > but how do I do this? CommonTokenStream does not seem to 
> provide any 
> > public method of inspecting non-default channels
> >
> >
> >
> I think that some clear example of this construction is 
> needed. Let me reiterate.
> Consider following constructs (as parser sees them):
> 
> (1) super
> 
> (2) super [TYPE] method
> 
> (3) [TYPE] method
> 
> (1) calls direct super method, (2) calls method on some 
> parent determined by TYPE, (3) calls static method on 
> arbitrary type Upon seeing (2) parser cannot decide whether 
> what it sees is really (2) or rather (1) followed by (3). So 
> I can use syntactic predicate binding [TYPE] to the nearest 
> 'super' construct, if present. Simply: ( super '[' ) => 
> super_alternative. But user might have really typed :
> 
> super; [TYPE] method
> 
> , which parser did not see because of ';' optionality.
> But this problem, in my opinion, is simply solved by saying 
> somehow: see all semicolons in this predicate - and that was 
> my original question's subject.
> If parser saw semicolons when executing predicates then it 
> could not match ( super '[' ) so it would fail, and it in 
> turn would lead to taking correct path. I hope my reasoning 
> is more or less clear to you. Thanks for any input.
> 
> 
> 
> 
> --
> Greetings
> Marcin Rzeźnicki
> 
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: 
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>