Re: --report

[Akim Demaille]

Hi Paul,

That's a lot for the feedback, and the English lecture :)  I really
needed the latter :(

| > From: Akim Demaille <address@hidden>
| > Date: 20 May 2002 20:11:47 +0200
| 
| > address@hidden 1
| > +
| > +The textual file is generated when the options @option{--report} or
| > address@hidden are specified, see @xref{Invocation, , Invoking
| > +Bison}.
| 
| I assume the "@sp 1" is a typo?

It was not, it's probably related to my LaTeX style where I like to
use \medskip more than people seem to use sp in Texinfo.  The point
was detaching the introduction from the body, but I'll remove it.


 
| > +As expected, @command{bison} reports that @samp{calc.y contains 1
| 
| I don't understand why the two words "As expected" are there.
| Perhaps they should be removed?

Well, given the grammar, it really is to be expected :)  OK, removed.


| > +Then states which still have conflicts are listed.
| 
| Change to:
| The next section lists states that still have conflicts.
| 
| (I prefer active voice to passive.)

I prefer too, but I've always been told, in particular in scientific
papers, to promote passive :(


| > +no such transition on a nonterminal symbol, and the lookahead is a
| 
| Sorry, I don't understand what the phrase "If there is no such
| transition on a nonterminal symbol" is getting at.  NUM and exp are
| both lookaheads; one is a nonterminal, the other a terminal.  Perhaps
| the point should be made that exp is a lookahead too?

Arg.  We disagree on the way to express gotos.  To me, it is an heresy
to name `exp' a lookahead here, both from the theoretical point of
view, and the implementation point of view.

| > +#define report_none        (0)
| > +#define report_states      (1 << 0)
| > +#define report_itemsets    (1 << 1 | report_states)
| > +#define report_lookaheads  (1 << 2 | report_states)
| > +#define report_all         (~0)
| > +extern int report_flag;
| > +/* Return TRUE iff THING ought to be reported.  */
| > +#define report_p(Thing)   ((report_flag & report_##Thing) == 
report_##Thing)
| 
| This is a fairly minor point, but I would parenthesize 1<<1 and 1<<2
| to avoid warnings with some compilers.  

Thanks.

| Better yet, I would use an enum,

I refrain using enums when I play bitwise tricks.  In such a
framework, the advantage of enums vs #defines is unclear to me (as, I
doubt that debuggers are able to report the value `a|b' as the string
`a|b' in case of enums.  Put after all, why not.).

Also, I remember I found once a compiler that complained about
operations on enums, which I appreciated.  ISTR it was SGI.

| and remove the funny dependency of report_itemsets on
| report_states.  I.e.:
| 
|   enum
|   {
|     report_none = 0,
|     report_states = 1 << 0,
|     report_itemsets = 1 << 1,
|     report_lookaheads = 1 << 2,
|     report_all = ~0
|   };
|   extern int report_flag;
| 
| and then in the rest of the code, uniformly replace:
| 
| report_p (states) -> report_flag
| report_p (itemsets) -> report_flag & itemsets
| report_p (lookaheads) -> report_flag & lookaheads
| 
| This will be easier to understand, for me at least

I agree, but it was not implementing the dependency between `state'
and the others.  That's why I preferred this way.

But I can see your point: this dependency is best expressed in the
argmatch tables.  I'll do that.

Thanks for all your useful comments!