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

[Steven T. Hatton]

On Wednesday 13 July 2005 10:51, Roberto Raggi wrote:
> 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.

Glad you agree. 

There is another, more intrusive way which *may* have some advantages.  That 
is, build some of the actual XML DOM into the nodes of the CodeModel (I think 
that's where it would go.) It's just an interface for nodes in a tree.  It 
would constitute adding member functions to the existing nodes.  That might 
make using XPath on the existing model possible.

It's just an idea, not a request.

> 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.

What happens if you run it against a memory resident DOM? Could you pull in 
enough of the dbxml to cover the working code loaded in the IDE?  If I 
understand the existing bdb mechanism (and that's a BIG IF) it is loading a 
file at a time.  I'm not really sure if that is once when the project is 
opened, or only when a given file is opened.

It seems reasonable that the same, or similar, could be done with dbxml. I 
guess if you had code that couldn't be parsed to fit into per-token XML 
elements, you could save it as raw text in a text node.  I'm pretty sure you 
could save each individual file as a DOM.  Gluing it all back together when 
you retreive it may be more difficult.

> 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 :(

Are you saying you need to live with code that won't parse?  What if you could 
take the part that won't parse and stick it in a text node of a DOM element 
until it can be fixed up? 

Again, these are just my thoughts.  If it seems useful, please use the ideas. 
If not, that probably means I'm wrong.
-- 
Regards,
Steven