[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Some tweaks
|
From: |
Hans Aberg |
|
Subject: |
Some tweaks |
|
Date: |
Wed, 26 Dec 2001 12:09:39 +0100 |
Some more of my Bison tweaks:
- If the Bison generated parser experiences an undefined number in the
character range, that character is written out in diagnostic messages, an
addition to the $undefined value.
Suggest: Change the name $undefined to undefined; looks better in outputs.
- For use with my C++ parser, I transported the "switch (yyn)" statement
that Bison writes to the bison.simple skeleton file. This way, I can remove
the current default rule $$ = $1 implementation, which causes a double
assignment to $$ which may not be OK under C++, replacing it with a
"default:" part within the switch statement.
Note that the default rule $$ = $1, when typed, is perfectly OK under C,
but in the C++ implementation I made, this rule is different from
$<type_name>$ = $<type_name>1. I therefore think that one should implement
a Bison option where every typed default rule is explicitly written out
(same typed ruled can of course be grouped together).
Suggest: I looked at the problem of making more tweaks, in the first hand,
to transport as much of the stuff that Bison writes to the skeleton file
(because that makes it easier to make support for another parser language,
as one then only need to change the skeleton file). The semantic parser the
get in the way, because it complicates the code.
So I suggest that one know removes the semantic parser: It is known to be
of no practical or theoretical value, is broken, nobody knows how to get it
going, and Corbett had himself it removed a long time ago (a decade) from
the Berkeley Yacc version he derived from Bison.
- I can describe my idea to work Bison up for multilingual support, in the
first hand for say C, C++, Java and XML:
In the skeleton file, the %% actions line is replaced by the actions, which
Bison writes as
case <rule_no>:
#line <line_no> "<file_name>"
{ <action> break; }
case <rule_no>+1:
...
Here are four variables, <rule_no>, <line_no>, <file_name>, <action>. One
simple way to enhance this might be to invent a macro
YYACTION(rule_no, line_no, file_name, action)
which the user can define. Bison would instead write the actions as
YYACTION(<rule_no>, <line_no>, <file_name>, <action>)
YYACTION(<rule_no>+1, )
And the skeleton file might have
#ifndef YYACTION
#define case <rule_no>:\
#line <line_no> "<file_name>"\
{ <action> break; }
Then, one might compile it directly for C, or by changing YYACTION and
running it through the C preprocessor, one might be able to produce a file
for a non-C language. The problem though is that this does not work,
because the C preprocessor will not treat these arguments as one might want
it; in addition, the output from the C preprocessor is unformatted, and
quite difficult to read.
So the next step would be to enhance the language that reads the Bison
skeleton file, so that one can tell it what one wants YYACTION to be (this
is what I did in my "formatter" program). This is in fact not so difficult,
because one does not even need macros, as the variables <rule_no>,
<line_no>, <file_name>, <action> already have their values in the file
writing context; it should suffice with just being able to define templates.
With this in hand, one might write in the skeleton file, if skeleton file
strings are enclosed in `...' (and ('\n') indicating a separation between
actions), say
define actions (`\n') {
`case ' <rule_no> `:
#line ' <line_no> ` "'<file_name>`"
{ '<action>` break; '
}
With a command
file <name>`.cc' { <body> }
one would write the <body> part to the file named "<name>.cc". If it
contains the actions command, the actions would be written in there
according to the definition of the actions.
This way a single skeleton file can be used to generate more than one file
(like a header and a source), and it is easy to edit for special purposes.
I think that one could start to tweak Bison, as to enhance it along this
path: First remove the semantic parser, and then successively moving the
text that Bison writes to the skeleton file and the formatter that reads
it, while retaining the parser algorithm information that Bison generates
within Bison, of course.
Hans Aberg
- Some tweaks,
Hans Aberg <=