[antlr-interest] internal error

[Jim Idle]

Perhaps better is to put the whitespace and/or new lines on their own 
channel, then use a gated predicate to see if there is one there or not 
at just the strategic points where it matters. For instance:

identifier
  (
     {( (TokenStream)input ).get( input.index()-1 ).getType() != WS }?=>

				DOT identifier
  )*

Jim

> -----Original Message-----
> From: Gavin Lambert [mailto:antlr at mirality.co.nz]
> Sent: Friday, February 01, 2008 2:34 PM
> To: Olivier Lefevre; antlr-interest at antlr.org
> Subject: Re: [antlr-interest] internal error
> 
> At 10:41 2/02/2008, Olivier Lefevre wrote:
>  >
>  >But I need a WS because I want to allow superfluous spaces
>  >anywhere, e.g. not just [1,2], [1, 2], [ 1 , 2 ] etc etc
>  >without encumbering the array rule with ( *) and such.
> 
> If it's just superfluous spaces you want to keep, then you can
> simply remove the newline characters from the WS rule and
> everything will be fine.
> 
> If you want to permit superfluous newlines as well then really you
> shouldn't be trying to match them at the parser level.
> 
> Ok, yes, it's in that example you posted, but that seems a bit
> dodgy to me.  As I said before that will do the "wrong thing" when
> faced with multiple newlines or newlines followed by other
> whitespace.
> 
>  >OK, maybe with experience one can decode it but do all runtime
>  >problems lead to blowups? Why doesn't it just say "Invalid
> input:
>  >[] at line 3" or some such?
> 
> Really that ought to produce a compiler warning (or error), since
> the ANTLR compiler ought to be able to figure out the cardinality
> in most cases (although as I said before there are some constructs
> that can be misleading).
> 
> At runtime though it's mostly too late.  You see, it's already
> successfully matched "[]" as valid input (which it is, according
> to your grammar), and now it's trying to put that into an
> AST.  The rewrite rule is telling it that there must always be an
> "elements" term, but as it happens it doesn't have one.  What else
> can it do but to blow up?
> 
> This is where having unit tests to exercise your lexer/parser is a
> good idea, since you'll catch this sort of thing at that point
> (assuming your test cases are comprehensive enough).
>