Re: beta testing

[Philippe Bekaert]

Hans Aberg wrote:

> >Ideally, there should be a switch so bison does not generate the YYSTYPE
> >union declaration in y.tab.c, but only in y.tab.h.
> 
> I do not use unions with C++: You could just as well make use of a derived
> hierarchy, and have a few extra fields, if the items are not to big.
Unfortunately, that's what bison and yacc generate. I would like to use
that because in this way, the YYSTYPE data structure is automatically
updated in all of my code whenever the union declaration in the bison
script is changed.

> Actually, I have absolutely no idea of what the final C++ support will look
> like.
Who decides about this? People on this list I hope??

> But, for my own use, I am writing on a formatter, a macro language, which
> is similar to TeX (having definitions within definitions), except that it
> outputs ASCII. One can also build environments beforehand, and then write
> out sequences using macros. I use this to write out C++ code.
> 
> With such a formatter tool, it would be easy to write out the correct code
> in whatever configuration, by changing a single formatting file.
The problem I want to solve with my project is remotely similar.

> But before we know what will happen with Bison C++ support, your ideas are
> as good as that of any. -- Please report here, if you succeed to implement
Can you give me some information what others have proposed?

> a working version. (The easiest way would be to have a single unchanging
I have a working version already! Just the documentation is lacking. But
before I start writing that, I'd like to know whether it makes sense or
not.

> header file, like the Flex FlexLexer.h header. In my opinion, though, it
> would be better to write a correct header for each program that Bison
> produces. Then, producing a corresponding FlexLexer.h header file would be
> the first step.)
Nothing needs to be changed to FlexLexer.h.

Note that I can solve the problem of generating parser objects already.
I am however working on a project which I'd like to distribute freely.
The project an extensible scene graph library for computer graphics
applications,  to be released under one of the GNU licenses. The ability
to write your own importer filters is an essential part of this project,
having bison generated parsers cleanly implemented and co-existing with
each other in parser objects. Therefore, I need bison support for
generating parser objects.

I will comply with whatever way to generate C++ parser objects you come
up. I do not insist on you taking over the way I solved the problem. But
please come up with something soon. I don't see why it should take so
long: you get the job done with extremely simple and limited and
compatible updates to the latest bison release.

The alternative is that I distribute a tweaked version of bison with my
code, but I guess that's not what you want either.

Philippe.

-- 
Philippe Bekaert
Post-doctoral Research Fellow
Max-Planck-Institut fuer Informatik
Im Stadtwald, Geb. 46.1
66123 Saarbruecken - Germany
+49 681 9325422 (office phone)
+49 681 9325499 (office fax)
+49 179 4503121 (private phone)