Re: --report

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: 25 May 2002 09:04:59 +0200

> | > +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 :(

Yes, scientific text often prefers the passive voice, when authors are
trying to focus on the process or principle rather than the actor.
For example, one would normally prefer "Subjects were selected
randomly from a pool of applicants" to "We selected subjects randomly
from a pool of applicants".

However, the passive voice is just a means to an end; it isn't
mandatory, even in scientific papers.  In this particular case the
discussion is about which sections of the Bison-generated reports
contain which information, and so we needn't use the passive voice to
avoid inserting ourselves into the discussion.  So here it's
reasonable (though of course not mandatory) to use the active voice.

Other GNU documentation advice suggests the active voice.  E.g.,
<http://www.gnu.org/manual/elisp-manual-20-2.5/html_node/elisp_655.html>
says:

  Write documentation strings in the active voice, not the passive,
  and in the present tense, not the future. For instance, use "Return
  a list containing A and B." instead of "A list containing A and B
  will be returned."


> | > +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.

Fair enough.  But I still didn't understand the text.  Perhaps you
might want to reread it with my confusion in mind.


> | 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.).

Many debuggers can't see defines, so you can't use such a debugger
to print the value of an expression that involves a defined symbol.


> Also, I remember I found once a compiler that complained about
> operations on enums, which I appreciated.

Long ago, there was disagreement in the C world as to whether enums
were like Pascal (each defining a separate type) or whether they were
just names for integers.  Many C compilers took a somewhat Pascal-like
view, and issued diagnostics such as the one you describe.  But that
disagreement was settled long ago, in favor of the Standard C approach
where enums are all integer types.  It's been many years since I've
run into one of those old compilers, and I don't expect to ever run
into one again.

There are of course some advantages to the Pascal-like rules, but the
modern consensus is that C enums are just integers, and we might as
well use that consensus rather than fight it.