[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Enable experimental report features?
From: |
Akim Demaille |
Subject: |
Re: Enable experimental report features? |
Date: |
07 May 2002 11:30:45 +0200 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) |
| A little of both. When I taught LR parsing, I had my students modify
| the GCC grammar for C,
What kind of massaging did you ask for? New structures?
| and I also had them write a grammar for Appel's toy language.
I love this language :) And yet it does pose a few interesting
challenges when looking for 0 conflicts.
| But wouldn't it be even easier yet, if Bison drew that path itself?
Oooh, yes, definitely. That's been on my stack for a long time, but
there are still many things to change in Bison before it can be done
simply IMHO. And I don't think it is reasonable for the next
release. I wanted to remove unit rules too, but it requires more
massaging of Bison that I originally thought :( That's for later too.
| 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.
Yep.
| > 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.
Looks good to me. Included in TODO.
| (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. :-)
:)