Re: LL(1) vs LALR(1) parsers

napi@ms.mimos.my says...
>Let's compare LALR parsers with LL ones:
>
>o Error detection and recovery (even)


What is this ?. I have used both LL & LALR based tools and this
experience has convinced me never to use an LALR tool again. The
trouble with LALR tools is simple. An LALR parser has no idea about
the context of the syntatic structure. Hence, this leads to two
massive problems. (1). Writing an LALR parser needs to be done with a
bottom up thought process which is unnatural (well it is for me
anyway). (2). The error detection has no idea of the context so it
can't select a natural recovery point and the error meesages produced
are consequently usually poor.


In summary, LL error recovery is vastly better than LALR. Moreover, a
lot of LL tools support automatic error detection and recovery. Most
of these tools ensure that the grammar is a 1-track LL grammar and
provide almost all the benefits of LALR with a lot of extra bonuses.


As an example of such tools consider the following simple rule:


ThisIsSomeRule( OUT Symbols ) =
        (
                /* Trap Error in First or Third part */
                [[ ERROR,0,0,"The whole rule is wrong" ]
                        CallFirstPart( OUT Symbols ),
                                [ /* optional but could be choice, iteration or recursion */
                                        /* Trap error for Second part */
                                        [[ ERROR,0,0,"The optional part is wrong" ]
                                                CallSecondPart( OUT Symbols )
                                        ]
                                ],
                        CallThirdPart( OUT Symbols )
                ]
        );


This is a simple example of how LL grammars can naturally support
error detection and recovery even when the situation is complex and
contains constructs such as choice, iteration or recursion. The above
is a factual example for an actual system. No other source code is
required for complete error dectection and correction by the system in
question. Obviously, lots more eoor traps could be added to trap
all-sorts of other problems without much effort.


Regards,


Mike
--

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