On 01/09/2011 05:39 AM, Joel E. Denny wrote:
> capturing the full sequence of characters that the user might have
> accidentally intended as part of the symbol name enables Bison to give
> more helpful errors and warnings.
That is an advantage, but it is a relatively minor one compared to the
co
On 9 Jan 2011, at 20:28, Paul Eggert wrote:
we document %token-table and yytname as deprecated
features and make Bison warn when %token-table is specified
This seems the better course to me. The feature does not sound
that well-thought-out; if nobody has the time to think it through
and do it
On 01/09/2011 07:18 AM, Joel E. Denny wrote:
> we document %token-table and yytname as deprecated
> features and make Bison warn when %token-table is specified
This seems the better course to me. The feature does not sound
that well-thought-out; if nobody has the time to think it through
and do
Hi John,
On Fri, 31 Dec 2010, John P. Hartmann wrote:
> I cannot answer your question directly, but maybe this will be of some
> help in the folklore department.
>
> Bison used to have an option to generate the just the tables
> (no-parser), which by the end of version 1 still worked sort-of. Y
On Fri, 31 Dec 2010, twlevo wrote:
> > On Thu, 30 Dec 2010 18:20:09 -0500 (EST), Joel E. Denny wrote:
> > > Oldest found doc about a option --token-table and %token-table is
> > > in gcc-1.22 or gcc-1.24 in bison.info.2 or .4 without a note how to use
> > > it.
> > Could you explain a little more
On Sat, 8 Jan 2011, Paul Eggert wrote:
>$x--
>
> is the same as
>
>$[x]--
>
> for the same reason, even if "x--" is an identifier. And, similarly,
>
>$--x
>
> is invalid.
Yes.
> > Because Bison reparses the reference later to find "-" and ".".
>
> Why does Bison need to repars
