Re: Synopsis - tutorials

Roman Yakovenko wrote:
> On 4/27/07, Stefan Seefeld <[email protected]> wrote:
>> If all you want are the declarations, the AST should be enough.
> 
> Yes, this is all I want. The exact requirements is here:
> http://language-binding.net/pygccxml/declarations_uml.png
> I saw similar diagram for Synopsis too. It could be nice to have
> access to comments associated with declaration, but it is not a must.

OK. This looks indeed quite like the AST representation. You do
have access to comments there, which are treated as annotations to
declarations. This may become interesting as you can embed any kind
of metadata (such as documentation), or even processing instructions
there...

>> What is hard is to figure out how the API should look like to be useful
> 
> I can start using it and provide the feedback to you. If I understand
> right the subject, than the best solution is not to have API at all. I
> mean Parser Tree, could be a tree, with a lot of nodes. The only
> needed API is "select" or "query".

Yes, the parse tree is very rich, and (at least right now), important
information isn't conveniently accessibly directly, but needs to
be looked up (the parse tree is really a tree, not a graph, so there
are no links from variable uses to their declarations, etc.).

The general approach to 'lookup' in the PTree, as well as the AST, is
to implement a special-purpose visitor that implements some form of
traversal of the representation, collecting the desired information.


> http://language-binding.net/pygccxml/query_interface.html - this is
> what I implemented for declarations tree. I've got very positive
> feedback.

Good. Yes, it's definitely possible to implement such an interface with
Synopsis.
I invite you to look into the Synopsis Processor / Pipeline design. The
idea there is that you ultimately want to define a transformation of
some input to some output. Thus, instead of using some imperative
approach I go the functional way: provide some node-specific transformation
rules, and then compose the processing pipeline out of (built-in as well as
custom) processor objects.
Since most individual transformations are pretty common, there isn't much
programming to do, i.e. the focus is on pipeline composition (which is
rather declarative in nature).

>> , as well as finish the parser
>> (anything related to type analysis, e.g. template instantiation, overload
>> resolution, etc.).
> 
> I don't think I can help you here. Also I have question: why do you
> write C++ parser in C++? Did you considered to write it in Python?

Parsing C++ is quite expensive, as it involves a lot of semantic analysis
(starting with a symbol lookup for all tokens that may be type ids, or other
identifiers). I'm worried about performance. (The main reason the g++ frontend
got noticeably slower over the years is because it has to do a ridiculous amount
of work to analyze the code, in particular if the C++ standard library is involved.

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...