|LL Parser problem firstname.lastname@example.org (2004-08-09)|
|Re: LL Parser problem email@example.com (2004-08-10)|
|Re: LL Parser problem firstname.lastname@example.org (SM Ryan) (2004-08-11)|
|Re: LL Parser problem email@example.com (Nick Roberts) (2004-08-13)|
|Re: LL Parser problem cfc@shell01.TheWorld.com (Chris F Clark) (2004-08-15)|
|Re: LL Parser problem firstname.lastname@example.org (Nick Roberts) (2004-08-23)|
|Re: LL Parser problem email@example.com (Richard Pennington) (2004-08-25)|
|[2 later articles]|
|From:||firstname.lastname@example.org (Jared Lessl)|
|Date:||9 Aug 2004 00:31:09 -0400|
|Keywords:||parse, LL(1), question, comment|
|Posted-Date:||09 Aug 2004 00:31:09 EDT|
I'm working on a parser (using Grammatica
http://www.nongnu.org/grammatica/) for AREV R/BASIC and have got just
about everything pinned down except for the usage of the '<'
character. In R/BASIC, it can be used both as a less-than comparison,
but also to index an array, e.g. "array<1,2>".
Obviously the array should be resolved before any comparisons (and
comparisons cannot be used as expressions within the array index), but
I find that it's doing so to the exclusion of comparisons. I.e., when
parsing "IF X < 2 THEN", it breaks, asking to know where the '>' is,
when all it has to do is work back up the tree and see that there's
another way for the '<' to be used, one that does not require a
I would have thought an LL(k) parser generator would be able to handle
that sort of ombiguity. Any ideas?
[Special case the lexer to return a mutant < token after an array
Return to the
Search the comp.compilers archives again.