[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sun, 30 Sep 2007 10:53:47 +0200
Le 30 sept. 07 à 08:53, Joel E. Denny a écrit :
Maye "simplifications" is too general, but it may fit.
I'm not really sure unused terminals fall into any of these
Does their identification reduce or simplify the grammar or parser
Well, useless items are indeed not used at all to compute
the automaton. The grammar is first sanitized.
They might be redundant or they might be used by the lexer to induce
a syntax error.
Unused tokens are the exception indeed: they are kept so that
the scanner can use them.
the "useless" and "unused" elements don't need to be grouped
inside a parent element. There's only one of each anyway.
example from Wojciech's web page:
I'm a bit surprised by the order that was chosen: it seems
more logical (to me) to start with the various categories
(nterm, rule, term) and inside each group to report useless,
unused etc. WDYT?
Do you mean you would group useless and useful rules together, for
No, I meant that I see no reason to group nterms, terms and rules
under "useless", but that I would group under terms "unused" and
Should we really repeat the rules then? Its number suffice:
the grammar is defined elsewhere.
Useless rules are eliminated from the grammar, so this is not a
Really? I thought we dumped the exact grammar before simplifications.
I checked by reading http://www.gnu.org.ua/~polak/hack/bison/xhtml/
which shows rule 3 both in the grammar section, and in the useless
BTW, maybe the grammar should
be defined first, and then the rest of the information. The
order should be chosen to please tools, not humans.
Would that change help tools significantly? If not, I figure we
well please the humans.
I kind of disagree here. The XML output should probably not be
designed to mock the *output. In fact, I might even suggest that
the grammar section itself annotates rules unused rules instead
of using another separate sections.
Similarly, IMHO, there should be only one section about terminals
including both their description (name, number, "string" etc.),
whether they are unused, useless etc. I don't see the point of
separating them at the XML level.
That would solve your "reduction" section naming problem, as
there would be no such section :)
Similarly, I'm not sure there should be a section about the
conflicts, since the states already provide this information.
I can be wrong, but I'd feel better if the XML file was
without redundancy, even if that requires a bit more work
from the XSLT tools. Work that I guess can be factored with
an XLST library tailored to our XML format (I'm using words
I understand, but which I never practiced for real, so I
might suggest stupid things here :).
On the contrary, as a human, I do want to have a table of
content of the conflicts. And I'm *first* interested in
the problems of my grammar, and then by the grammar itself.
While tools would certainly prefer to see the grammar
defined, and then facts about it.