Re: METHOD DR

[Hans Aberg]

At 15:35 +0200 2001/06/15, Axel Kittenberger wrote:
>> >Hans> In the code I use now for the "formatter",
...
>I would love to see such a feature, right now I've a modified rip-off
>version of bison, which users need first to download, compile and install.
>If one could provide his own formation rules with your compiler the step of
>providing your modified bison package could be scrapped.

Right. This is one point.

>One thing for the start would be to produce the token definitions as enums,
>that doesn't make any difference in C, but can come a lot handier in C++, as
>#defines pollute all name spaces, while an enum would only apply to the
>defaultl namespace. Like if you've
>#define IDENTIFIER 257
>you cannot use a variable or constant called `IDENTIFIER' inside classes,
>which normally would override the default namespace, but if I defined it
>this way:
>enum {
>  IDENTIFIER = 257;
>};

Right, this is another point: To get rid of all those processor # macros if
one so will.

The approach I sue now is to work only with strings, and one would thus a
table look-up (or "environment") where the string "IDENTIFIER" produces the
string "257". Then, by a macro, one can write it out as one pleases. IN
C++, it would be more appropriate to use say
  namespace my_parser {
    const int IDENTIFIER = 257;
  }
and one would get rid of the macro pollution.

>>... having to learn
>> >yet another language to define the output format seems overkill to me.
>>
>> A skeleton file is already a "language" which has to be learnt.
>
>What I've seen some people refrain to use bision because they don't
>understand the existing skeletton or output.

The style of my macros is not that complicated (and it would be easy to
accomodate the syntax for use with Bison): For strings, I use `...'.

My C++ output header needs to include a series of C/C++ headers. So I have
a macro
  define header_std_headers{
    within include_std (`\n') {`#include <' file_name `>'}
  }
for that: One builds a sequence of environments where each contains the
lookup variable "file_name" with the filename. The (`\n') says that the
output of the sequenced environments should be separated by a newline \n.
Since I want the names in alphabetical order, I use std::map to sequence
these environments.

The macro that produces the C++ header file then contains
  define header{
  `
  #ifndef ' header_full_name `
  #define ' header_full_name `

  #if !__cplusplus
  #error Header file "' header_full_name `" only for C++.
  #endif

  ' header_preamble `
  ...
  }
where I write out the #include file names by the macro
  define header_preamble{
    <$header_std_headers>
    <$header_headers>
  }
Here, <...> is a special construct that allows one to format the output into
columns. It should not be needed here, it is useful if one wants to make the
output more readable.

It may be complicated, but probably not so if one has an example file, and
merely wants to modify it.

>> >Hans> Another approach would be to work the formatter up as a separate
>> >Hans> language so that the environments can be built from a file,
>> >Hans> written by Bison. One can then merge this with a macro formatter
>> >Hans> file (corresponding to the current Bison skeleton files) in
>> >Hans> order to produce the output parser code.
>
>Just to throw an managment bingo word in :o) maybe XML reasonable?
>Donnot know, see it as brainstorm input...

No, in those language, one cannot (conveniently) first build these
environments and then merge them with the formatting macros.

The two additions that would be needed are first a command for creating
such environments, and second a command for writing a macro to a file.

>> >But bison by itself just outputs tables.
>>
>> Plus some action rules, I believe.
>
>Plus the #defines for the header file.

So there are a number such things that Bison writes that one would like to
be able to format in a more specific format.

>And yes the action definitions, other languages don't have the union type.

And unions does not work in C++ with types that have con-de-structors. So
perhaps one would want to be able experiment without painstakingly modfying
the Bison sources every time.

>BTW, thought last time about another thing while looking on the code, I've
>seen the code generating the tables checking it will not grow over the size
>'short int' for the compiler. But who says the generated parser tables are
>for the same processor/compiler as bison was compiled for? There is no way
>bison could at runtime figure out how large 'short' will be for the
>output...

So yet another point one would be able to control: As you say, it is quite
common to make a distributed parser that should run on sequence of
compilers.

  Hans Aberg