Re: [cdt-dev] Question about parser

[John Camelon <jcamelon@xxxxxxxxxx>]

cdt-dev-admin@xxxxxxxxxxx wrote on 10/03/2004 10:14:32
PM:

> Current implementation of parser does not provide complete model.
For 
> example, parser processes statements and resolves/collects references,
> reports about syntax problems. But it does not collect information
about 
> statements, there are no corresponding AST classes, and requester
> interface doesn't have callback methods for statements processing,
> aren't there?.  

Correct, there have been numerous threads on cdt-dev
& cdt-core-dev concerning this.
Doug is defining a new set of AST interfaces that
we shall start to migrate our
parsing framework towards in the AST2 branch.  Also,
Jason Brown has been doing his
own exploration in this area in his environment.  It
should not be a surprise that 
the current parser does not provide statement-level
granularity in the AST.

> I realize well that this functionality is not
required 
> for the tasks that use parser service now. Working on code formatter
> implementation I tried where it was possible to subclass parser classes
> in order to get desired behavior. So far it did not required essential
> efforts. 

I still do not understand how you get this to work
purely through
subclassing and substitution.  What parse mode
do you use?  How do you 
rewrite the source?

> In this case I could also follow the same way.
Before doing 
> that, I just was wandering about plans of parser development. I found
> out in new ast2 branch packages named "dom" (now empty).
 

"dom" is from CDT 1.1.  Everything
new is also included in the "parser"
source folder.

> If we should 
> expect to see this stuff soon, it would be a wast of time to torture
> existing parser in order to compel it to do the things it cannot do
now. 

To be honest, I was suprised to hear that you were
trying to use the 
parser to do source code formatting.  In previous
conference calls it was 
suggested (by Rockwell Collins I believe) that the
short-term solution 
for this would be to integrate external code formatters/pretty
printers into 
a framework.  

We do not plan to merge AST2 back into the HEAD until
we have migrated as many of
our clients as possible to how the parsing framework
is supposed to work.  Our focus
now is on restructuring the architecture, and this
will take some time (most likely
towards the end of the year). 

> On the other hand, if this is not a correct assumption, doing this
work 
> probably makes sense because using ineffective code formatting engine
> even if this one later will be redesigned using new parser services,
can 
> help to design and test engine-independent UI (not a small, BTW) and
to 
> approve formatting technology in general.

I'm not sure what you mean, please explain.  

JohnC