faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: "Kuanta" ...are you kidding or what?
by Spy Hunter on Tuesday 26/Jul/2005, @11:35
|
I have always thought that the best way to improve parsing of incorrect code would be to give the parser some memory of recent changes. For example, if the project started out as completely valid code and then you modified a method definition (without changing the code that callst the method), it would be hard to parse the resulting invalid code, but if the parser remembered that the old method used to exist it could make many simplifying assumptions as it parsed the new invalid code and give more helpful error messages too ("method foo has been changed to bar" instead of "unknown identifier 'foo'" or the like).
Are there any plans or ideas out there for this kind of parser? |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: "Kuanta" ...are you kidding or what?
by Eric Laffoon on Tuesday 26/Jul/2005, @19:56
|
I don't know of any plans to do a parser like you describe. Parsers are tedious and involved code that takes a lot of time and debugging. As far as providing better error messages I think your example shows how much more complex it really is. For a relevent changed method message you would need persistant memory of changes for both files which would be like incorporating a revision system into a parser. It's an interesting idea, but parsers have to process so much data optimization is a key factor and making them revision aware would likely be a nightmare and slow. A more ideal system would be to offer the option to find and change the relevent method calls in the project or put them in an edit queue. My preference in adding automation is that it actively seeks to reduce errors.
BTW I am not aware of everything going on with the KDevelop parser, just what we've been doing with Quanta so far. That's the perspective I'm looking at. It will be exciting to review using their parser in places or possible integration and modular parsing concepts. We will have inherent differences as well as similarities.
|
[
Reply To This | View ]
|
Telepathic parsers possible?
by Richard Dale on Tuesday 26/Jul/2005, @23:29
|
'..but if the parser remembered that the old method used to exist it could make many simplifying assumptions'
You really talking about code refactoring here, where the IDE has parsed the source and formed an 'Abstract Syntax Tree' and symbol table of what the names used in the program code mean. Then because it knows about the structure of the code, and not just the correctness of the surface syntax, you could specify refactoring rules to transform the AST. For instance, you could add some text before or after a node, or you could move a node to another part of tree. Moving a method to another class, or renaming a method and fixing up all references to it in the code are examples of refactoring. The new parser generator and language parsers for KDevelop 4.0 will be able to use a common refactoring engine, which will work with ruby just as well as C++.
If a syntax checker was giving you errors based on what the code looked like 5 or 10 minutes ago it would just be really annoying, and feel more like the editor had only half saved your work. There's no way it would be possible to 'read you mind' to find out what you were intending to do. Hence, the need to work at a higher level than typing in lines of text, like using a refactoring engine.
|
[
Reply To This | View ]
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
