Re: METHOD DR

[Axel Kittenberger]

> >Hans> In the code I use now for the "formatter", the environments are
> >Hans> built directly in C++ using features like std::map, so if you
> >Hans> want to hook that up with Bison and keep it C, you will end up
> >Hans> with some problems. I think it will be very tricky trying to
> >Hans> convert it into C code, as it is heavily OO.

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.

> >There are not that many languages we could aim at, and 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.

> And I figure you would extract only parts you need for making a C/C++
> output simple, as for a start.

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;
};
I can still use this token in other namespaces.

> >And there are languages for which you shall not use $ or @, Perl comes
> >to my mind. So even on the input language, we're doomed.

Or one could assign his personal favorite variable definer in the beginning
of the file?
like:
%prefix '$';

> >Java is very happy with its own set of tools, so is ML, Perl now has
> >very powerful LL generators and so on, Ada (Gnat) too.  And so on.

Just an stupid question, what is LL?

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

> >But bison by itself just outputs tables.
> 
> Plus some action rules, I believe.

Plus the #defines for the header file.
And yes the action definitions, other languages don't have the union type.
This can be easily work arounded in having the standard token of the type
<void *> or the alternative form of that in that language (like 'Object')
and to make typecasts to the actual type, instead of '.' accesses to the
union. However this also needs to be changed inside of bison.

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



-- 


GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

--
GMX Tipp:

Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a