Re: Bison's semantic parsers

[Hans Aberg]

At 02.36 -0700 0-10-10, Vern Paxson wrote:
>> Vern, could we imagine that Flex be put on the CVS server of the FSF,
>> subversions.gnu.org?
>
>Thank you very much for the offer, I certainly appreciate it.  However,
>Dick King has already volunteered to take over maitenance and development.
>I've cc'd the address he's using for flex-related mail, address@hidden

At 11.43 +0200 0-10-10, Akim Demaille wrote:
>Hans> Perhaps Bison and Flex should be bundled, or tuned up together.
>
>It's a good but bad idea.  For instance you could also argue that
>Autoconf, Automake and Libtool be merged, but if you just observe that
>they have totally different evolutions, it becomes infeasible.  While
>definitely a seducing idea, it wouldn't work IMHO.

My experimenting with C++ though suggests that Bison and Flex needs some
synchronizing if one should take full advantage of that language:

-- One thing that come to my mind is that instead of letting the Bison
output .cc file include the Flex .cc file, they communicate the information
via header files.

-- When experimenting C++ manipulator style I mentioned before
    Parser parser;
    parser_value val;
    ifstream ifs("...", ios_base::in | ios_base::binary);
    ofstream ofs("...");
    if (ifs) try { for (;;) {
        ifs >> parser >> val;
        cout << val << endl;
    }
I experience problems with how Flex resets its state, and how streams and
such are initialized.

For example, if I try to gobble up UNIX, MacOS & DOS line separators in Flex by
    \n|\r|\r\n           { return '\n'; }
then, when Flex sees a \r it must first look ahead to verify the next
character isn't a \n. However, if a successful value "val" is produced,
then the next time  one ends up at the line ifs >> parser >> val, Flex is
reset, and as a consequence, the extra character needed to the \n check is
gobbled up.

One can get around this by not allowing this ifs >> parser >> val
construct, then the advantage of freer, and therefore easier user syntaxes
are lost.

-- I think that there might be some other issues, such as how to properly
localize all data that Bison and Flex uses, and how they should communicate
that. These are more questions of hand-shaking than bundling them together
as a single program.

As for the comparisons of Bison and Flex versus other types of
compiler-compilers, I think the main disadvantage with them (the former) is
that they are extremely difficult to debug. It's rather hopeless trying to
debug the C/C++ files they produce as output. If one could hook up an
debugger though, so that one could step throw the .l/.y source files, just
as in the case of visual debugging of a C/C++ file, then this would change,
and it would not make any difference of what method is used, as long as it
is efficient and does the job.

  Hans Aberg