[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Enable experimental report features?
From: |
Paul Eggert |
Subject: |
Re: Enable experimental report features? |
Date: |
Mon, 6 May 2002 10:09:27 -0700 (PDT) |
> From: Akim Demaille <address@hidden>
> Date: 06 May 2002 14:17:14 +0200
>
> There are two kinds of novices: I'm referring to people trying to
> understand the theory, and toying with small grammars, and it looks
> like you are referring to people working on real grammars, trying to
> debug them.
A little of both. When I taught LR parsing, I had my students modify
the GCC grammar for C, and I also had them write a grammar for Appel's
toy language.
> My experience shows that to properly understand a conflict, you have
> to find the path in the automaton from the state 0 to the state having
> the conflict. This is _much_ easier to find when you have the whole
> item set displayed.
OK, I can see where a novice might find it easier.
But wouldn't it be even easier yet, if Bison drew that path itself?
As a side benefit, you wouldn't need to output all the verbosity; you
could include the "relevant" verbosity, i.e. only the verbosity that
contributes to a path to a conflict.
> So, it seems clear that it has to be an additional option :)
There will be further such options in the future, so I'd make them all
operands of the --report option. E.g., you could do something like this:
--report=state --report=lookahead --report=itemset --report=conflict-path
where "--verbose" is equivalent to "--report=state", and where
"--report=conflict-path" reports each path to a conflict state.
(As a minor point, I prefer avoiding plurals in option names. It's
partly for brevity, and partly to avoid wearing out the 's' keys in
our keyboards. :-)