316 |
* Parsing grammars |
* Parsing grammars |
317 |
Rewrite the reader in Bison. |
Rewrite the reader in Bison. |
318 |
|
|
319 |
|
* Problems with aliases |
320 |
|
From: "Baum, Nathan I" <s0009525@chelt.ac.uk> |
321 |
|
Subject: Token Alias Bug |
322 |
|
To: "'bug-bison@gnu.org'" <bug-bison@gnu.org> |
323 |
|
|
324 |
|
I've noticed a bug in bison. Sadly, our eternally wise sysadmins won't let |
325 |
|
us use CVS, so I can't find out if it's been fixed already... |
326 |
|
|
327 |
|
Basically, I made a program (in flex) that went through a .y file looking |
328 |
|
for "..."-tokens, and then outputed a %token |
329 |
|
line for it. For single-character ""-tokens, I reasoned, I could just use |
330 |
|
[%token 'A' "A"]. However, this causes Bison to output a [#define 'A' 65], |
331 |
|
which cppp chokes on, not unreasonably. (And even if cppp didn't choke, I |
332 |
|
obviously wouldn't want (char)'A' to be replaced with (int)65 throughout my |
333 |
|
code. |
334 |
|
|
335 |
|
Bison normally forgoes outputing a #define for a character token. However, |
336 |
|
it always outputs an aliased token -- even if the token is an alias for a |
337 |
|
character token. We don't want that. The problem is in /output.c/, as I |
338 |
|
recall. When it outputs the token definitions, it checks for a character |
339 |
|
token, and then checks for an alias token. If the character token check is |
340 |
|
placed after the alias check, then it works correctly. |
341 |
|
|
342 |
|
Alias tokens seem to be something of a kludge. What about an [%alias "..."] |
343 |
|
command... |
344 |
|
|
345 |
|
%alias T_IF "IF" |
346 |
|
|
347 |
|
Hmm. I can't help thinking... What about a --generate-lex option that |
348 |
|
creates an .l file for the alias tokens used... (Or an option to make a |
349 |
|
gperf file, etc...) |
350 |
|
|
351 |
|
* Presentation of the report file |
352 |
|
From: "Baum, Nathan I" <s0009525@chelt.ac.uk> |
353 |
|
Subject: Token Alias Bug |
354 |
|
To: "'bug-bison@gnu.org'" <bug-bison@gnu.org> |
355 |
|
|
356 |
|
I've also noticed something, that whilst not *wrong*, is inconvienient: I |
357 |
|
use the verbose mode to help find the causes of unresolved shift/reduce |
358 |
|
conflicts. However, this mode insists on starting the .output file with a |
359 |
|
list of *resolved* conflicts, something I find quite useless. Might it be |
360 |
|
possible to define a -v mode, and a -vv mode -- Where the -vv mode shows |
361 |
|
everything, but the -v mode only tells you what you need for examining |
362 |
|
conflicts? (Or, perhaps, a "*** This state has N conflicts ***" marker above |
363 |
|
each state with conflicts.) |
364 |
|
|
365 |
|
|
366 |
----- |
----- |
367 |
|
|
368 |
Copyright (C) 2001, 2002 Free Software Foundation, Inc. |
Copyright (C) 2001, 2002 Free Software Foundation, Inc. |