RE: bug report: incorrect warning about superflu ous syntactic predica te
> From: mzukowski@......
>That requires WS to be there. I'm doing this for element tags like:
> That won't work like the original, which required WS before
> an Attribute.
> ( Attribute (WS!)? )*
> > WS :
> > ( ' '
> > | '\t'
> > ) (WS)?
> > ;
<ABC> <ABC N1="V1"> <ABC N1="V1" >
The 1st requires no WS after the name ABC.
The 2nd requires WS before the attribute N1="V1".
The 3rd has optional WS after the attribute.
I think you were right the first time. Using a syntactic predicate appears
to be the only way to cover all 3 of these possibilities.
- mzukowski@... wrote:
>I have been able to get rid of almost any ambiguity this way.
> You seem to like this style of tail recursion. Why not:
> WS :
> ( ' '
> | '\t'
> This avoids the method call for every character beyond the first.
I think it happens because Lexer only has to match one token before it
Whereas ()+ causes follow ambiguities. I only use it when I am forced
This is only useful for parsing lines , where the depth is limited to a
small number anyway. I have a parser written in pccts 1.33 where *.g
are pretty huge.
% wc -l *.g
I started using this method when antlr would run out of memory
> From: "William J. Koscho" <wkoscho@...>The problem with that is that the last WS* will eat up all the white space,
> > >
> > > I have a construct similar to the following in a lexer rule:
> > >
> > > (
> > > ( (WS)+ Attribute ) => (WS)+! Attribute
> > > )*
> > >
> > > (WS)*!
> > >
> ((WS)* ( WS+ Attribute WS*)? )*
> or is there ambiguity because of (WS)* ( WS+ ....)?
> I think there might be...
> if there wasnt ambiguity, I would think this would match:
> <ABC> or <ABC N1="what"> or <ABC N1="what" >
then you start the loop over and the WS+ will fail. The best way to figure
out what will happen is to browse the generated code.