[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: <reductions>

From: Akim Demaille
Subject: Re: <reductions>
Date: Sun, 30 Sep 2007 10:53:47 +0200

Le 30 sept. 07 à 08:53, Joel E. Denny a écrit :

Hi Akim,


Maye "simplifications" is too general, but it may fit.

I'm not really sure unused terminals fall into any of these categories. Does their identification reduce or simplify the grammar or parser in any

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.

Or perhaps
the "useless" and "unused" elements don't need to be grouped together inside a parent element. There's only one of each anyway. Here's an
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

        <rule number="6">
            <symbol class="terminal">STR</symbol>

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 errors.xml.html
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 might as
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]