fredt wrote:
> My assessment of the whole project can be summarized below:
> 2. If we want to introduce a new parser, a lot more than what the current
> crop of parser generators can do is necessary in order to achieve the
> current level of performance and simplify future development. I won't get
> into the details here but I have previously outlined what has to be done. It
> is a fairly large project to develop a specialized generator / compiler on
> top of CUP.
Some thoughts to consider:
The gcc people replaced their existing generator-generated parser with a
handwritten recursive descent parser to improve compliance (some legal
C++ didn't work before that) and performance of the parser.
The current recursive-descent parser is rather easy to read -- I got it
immediately, I have more problems with parser specifications because the
semantics of code annotations and 'magic' names in code are not obvious.
And as a plus it's a lot easier to build hsqldb if it's not necessary to
download { the most current | a specific } version of some compiler
generator.
I compared hsqldb to the Axion DB a while ago, and I found their code
considerably harder to read and in it's current state it does far less
than hsqldb. It's parser is written using JavaCC. Compare the build
instructions to those for hsqldb: http://axion.tigris.org/building.html
So my suggestion is: Stick with the recursive descent parser. I works
well and should be reasonably easy to extend, from what I saw.
Thanks for listening
Harald
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
hsqldb-developers mailing list
hsqldb-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
