Re: Tool support for resolving LR conflict

torbenm@diku.dk (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
10 Sep 2005 12:37:29 -0400

          From comp.compilers

Related articles
Tool support for resolving LR conflict alpanad@gmail.com (2005-09-07)
Re: Tool support for resolving LR conflict torbenm@diku.dk (2005-09-10)
Re: Tool support for resolving LR conflict 148f3wg02@sneakemail.com (Karsten Nyblad) (2005-09-17)
Re: Tool support for resolving LR conflict alpanad@gmail.com (2005-10-02)
Re: Tool support for resolving LR conflict schmitz@i3s.unice.fr (Sylvain Schmitz) (2005-10-04)
| List of all articles for this month |

From: torbenm@diku.dk (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
Newsgroups: comp.compilers
Date: 10 Sep 2005 12:37:29 -0400
Organization: Department of Computer Science, University of Copenhagen
References: 05-09-027
Keywords: parse, LR(1)
Posted-Date: 10 Sep 2005 12:37:29 EDT

alpanad@gmail.com writes:


> Does there exist any tool support which aids grammar writer in finding
> out possible causes of LR-parser conflict and further give him some
> hints to resolve them? If yes please provide me relevant links.


The parser generator itself should be able to aid the grammar writer
in fainding the cause of the conflict. I does so by showing a
readable representation of the set of LR(0) itemsets and the actions
on each symbol. This requires some knowledge of LR(0) construction to
be helpful, though.


In some cases, it should be possible for the parser generator to see
that the cause of a conflict is ambiguity, and show an example of a
string with multiple parses as an aid to the user, but I don't know of
any parser generator that does that. And I find that it is the
conflicts that are not caused by ambiguity that are the hardest to
find and resolve, so I doubt it will help much.


As for giving hints to resolve the conflicts, that is more
problematical, as the parser generator will have no way of knowing
which of several parses will be more correct. Also, some conflicts
can be resolved by adding operator precendences while others may
require extensive rewriting. Like above, the parser generator could
show alternative syntax trees and let the user select which one they
prefer and then solve the conflicts accordingly, but this will not
help for conflicts that require rewriting of the grammar, which are
the most difficult conflicts to solve.


So, IMO, it is possible to make such tools that could give aid in
detecting and solving very simple classes of conflicts, but I doubt
you can get anything useful for the more difficult cases.


                Torben


Post a followup to this message

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