Re: language neutral parser

[Akim Demaille]

>>>>> "Axel" == Axel Kittenberger <address@hidden> writes:

Axel> But again this appeals to something I asked already before. What
Axel> is really the exacter mission of the official bison project?

For the time being, satisfy the most urgent needs, i.e., good C
parsers, and asap, C++ parsers.  If there are means to improve the
service, then we are ready to accept new code.  But for the time being
we will simply refuse because as is today bison is a hairy mess.

One part of the next steps of its modernization consists in clearly
separated input, process, output (which is not even the case right
now).  This should also help integrating other parsing technologies
(there is demand for full LR(1), and a proposal for DRLR(1)).

So

1. 1.30 which is a better 1.28 plus a few bells.
2. 1.50 or so, which is producing C++ and revamping the handling of
   the skeletons (Java might come for free or almost).
3. 2.0, better layout, more ``pluggable''.

Step 3. might be the right time for XML.  But currently it is way too
soon, bison is not ready for this.  I'm really sorry about that.  But
if you want to get your XML output soon, please consider helping the
development of Bison.

Axel> Just tinker in the old source somewhat, here and there? Create a
Axel> C parser generator only? Maybe now a bit C++ also. Be an
Axel> universal parser generator? Maybe help and encourage to develop
Axel> new parser technologies? 

Unfortunately Bison belongs more or less to the past.  Modern parsing
is almost systematically based on LL, people leave LR because of all
its problems.  And I don't think Bison should come with LL solutions.
But maybe someday it will, if 2.0 is modular enough.

So fighting for Bison is a noble, but somewhat lost cause.

Axel> In addition to the difference of usual make the results
Axel> available public. I guess there are dozends of better parser
Axel> generators, but all closed source, or company intern after all.

Agreed.  For instance, I'd love to see another backend than table
driven.  Direct implementations with functions are reported to be much
more efficient, in particular because they more opportunities for
compiler optimizations.

Axel> - There alphabet constists of far more than C.  - Axel

Yep, X comes to my mind :)