New parser branch (Was: Dumping the source DOM?)

[Roberto Raggi]

Hi Richard!

On Wednesday 13 July 2005 13:36, Richard Dale wrote:
> On Wednesday 13 July 2005 13:55, Roberto Raggi wrote:
> Ashley Winters is suggesting using an xml translation unit dump for the
> next version of the Smoke bindings library. And he is also suggesting doing
turns the AST into an xml file should be easy. You must create a visitor that 
coverts the nodes into an xml node.

> the runtime introspection via xpath, on xml files as text inside .so
> libraries, one per class. Hmm, he has done some sizing and performance
> testing and it didn't come out too badly.
well it is if you want to use it in a realtime environment. I tried a couple 
of months ago with dbxml and it was very slow.

> We had a discussion about this sort of thing at the Kiev conference. I've
> started work on using the bison grammar that is part of ruby for the next
> KDevelop 3.3 class browser instead of regular expressions. The only
> definition of the ruby grammar is the bison grammar, and it wouldn't be
> very easy to go straight to using Roberto's parser generator. So I do the
> bison first, and then the new LL(1) grammar for KDE 4/Qt 4.
great!!

>
> I had these questions to ask him about how the top down recursive descent
> parser compared with a bottom up ruby one:
>
> - Speed?
>   Roberto has measured his parser and it is faster than bison.
it seems faster.. 

>
> - Ease of use?
it depends.. from your grammar.. for instance removing the left-recursion in 
the C++ grammar is pretty annoying :-)

>   It has nearly all the features of bison except associativity and
> precedence hints in the grammar. You can't use left recursion, and so for
> ruby a small number of grammar rules about lists of method arguments would
> need to be changed.
exactly

>
> - Error recovery?
>   Apparently easier with the new LL(1) generator. Although bison seems fine
> to me and I will just have to add a few more 'error' rules to skip to the
> next valid  token. But top down parsers have a 'better idea' of what their
> currently doing, than bottom up ones.
I'm working on the error recovery engine. I have a couple of ideas to mix 
"correcting" and "non correcting" error recovery. Unfortunatly in KDevelop we 
need the AST so a full "non correcting" error recovery is not an option. Even 
if it produce a better result :(

>
> - Language independent?
>   The parser generator and refactoring engine will be language independent,
> and I would like to use ruby as a test case to ensure they are. Roberto is
> keen on Java and I think he will ensure their is nothing C++ specific that
> won't work with a Java parser. It would be nice to have an access type of
> 'package' as well as the usual 'private', 'protected' and 'public' in the
> language independent parts.
:-)

ciao robe