faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: "Kuanta" ...are you kidding or what?
by manyoso on Tuesday 26/Jul/2005, @05:26
|
<i>"Are there plans to leverage on gcc 4.0 and its parser to better understand the languages?"</i>
No.
And before you protest, yes, I know gcc 4.0 has the best c++ parser around. Yes, I know it _seems_ like it'd be a no-brainer to 'leverage' this for things like code completion and refactoring. Unfortunately, that is not how these things work and it is a naive assumption. A code completion parser requires the ability to parse incorrect code or half completed statements and not choke and throw an error.
That said, the new kdevelop _will_ have a brand new parser that will hopefully go a long way towards improving things. Cheers. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: "Kuanta" ...are you kidding or what?
by Debian User on Tuesday 26/Jul/2005, @06:26
|
Hello,
I do not reserve the right to protest. I have only asked and in no way intended to offend anybody involved.
I do reserve the right to be naive, despite being a "developer" what ever that means. :p
That said, I don't think that code completion and gcc 4.x are probably worth to marry. The gcc parser understands so many languages in near perfect ways. It gets some performance tuning and stuff that a separate parser engine would not have.
Even though it may be hard, maybe it's worthwhile? Do you know if somebody has actually tried it? I might be willing to try it myself...
Yours,
Kay
|
[
Reply To This | View ]
|
Re: "Kuanta" ...are you kidding or what?
by Morty on Tuesday 26/Jul/2005, @06:34
|
You know it's rather easy to try too, and you will see it's not good. Take some half-finished code with errors and watch the gcc 4.x parser barf on it. Then try visualize how that can help you with code completion when writing the said code.
|
[
Reply To This | View ]
|
Re: "Kuanta" ...are you kidding or what?
by manyoso on Tuesday 26/Jul/2005, @07:13
|
It is ok if you are not a developer, but just understand that what seems obvious to you is actually quite naive in actuality. Now, if I sounded hostile it is because there was a very long thread recently on kdevelop-devel that had a lot of _developers_ who were postulating the very same thing. All of them had never written or worked on a code-completion in kdevelop before.
And once again, I know you think it would 'probably worth to marry', but you would be WRONG. This is a naive belief that roughly goes:
"Hmm, we need a great C++ parser for code completion"
"Well, g++ is probably the most complete we could use"
"BINGO! That's a great idea, we should use g++!"
But, once again, this is WRONG!
The parser might be the best at parsing and compiling compilable code, but it sucks as a code completion parser. A code completion parser must be able to parse _incomplete_ uncompilable code. And it can't just produce an error and stop. Think about it...
In short, the g++ parser would have to be so heavily modified that it would lose the advantage of sharing code with the gnu folks. It would fork and diverge. Not only that, but the actual g++ parser would be a pain to retarget and modify -- and yes, I've looked and have actually hacked on both g++ and kdevelop's code completion and parser.
|
[
Reply To This | View ]
|
|
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?
|
[
Reply To This | View ]
|
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)
