Re: parsing in VB

Marc Font <mfont@recercai.com> wrote:
>I'm doing a parser for Visual Basic with Java. The other day, looking
>for information about it in Internet, I read that Visual Basic is not
>a LR(1) language. I'm using Visual Parser, which implements a LR(1)
>grammatic, and before implement all the tokens of VB i'm interested in
>knowing if it's true that it isn't a LR(1) language (because if it is
>true, i'll be forced to change my development software).


The easiest way to find out would be to just feed your grammar into your parser
generator and see what it does. Any parser generator (I'm not readily familiar
with Visual Parser) worth anything will tell you what production(s) are causing
shift-reduce or reduce-reduce conflicts.


There are numerous ways to deal with such conflicts:


1) Try to modify the grammar so that the language recognized is the
same but the grammar is LR(1).


2) "Hack" the grammar as the moderator suggested. If the conflicts
are caused by minor or rarely-used language features, then work around
them and issue warnings.


3) Have multiple passes: in the first n passes you run a pre-processor
over the input that "massages" it into the language your parser
recognizes.


One or a mix of the above is probably better than trying to find a
parser that recognizes a bigger set of languages than LR(1). In fact,
I'm surprised to see a commmercial parser-generator that uses LR(1):
the CFSM's for LR(1) parsers are generally considered too large and
unwieldy; particularly if you are recognizing a language as large as
VB.


Regards,


Cam


--
/ Cameron Bateman
/ 4B MATH/CS
/ University of Waterloo

Return to the comp.compilers page.
Search the comp.compilers archives again.