Re: Re: software design clarification

On Tue, 2007-05-08 at 23:05 +0300, Roman Yakovenko wrote:
> On 5/8/07, Stefan Seefeld <[email protected]> wrote:
> > Understood. Taking this very high-level description, I would express it
> > like this in Synopsis:
> >
> > A code-translating processor takes an AST (or similar) as input, and
> > generates some new AST as output. A formatting processor then traverses
> > the newly generated AST, 'formatting' it into actual code.
> >
> > The first processor would need to understand the code mapping, i.e.
> > understand the boost.python logic, the wrapping, call policies, etc.,
> > and the second processor would encapsulate formatting constraints, i.e.
> > how the generated code should be laid out, partitioned into files, etc.
> >
> > The two processors would be customizable (to differing degrees; for some
> > aspects a simple parameter is enough, for some you may want to encapsulate
> > subtasks into classes that can be overridden by users).
> 
> Basically you are right.
> 
> > >> The reason I ask is because I can see yet a different interaction between
> > >> Synopsis and Py++ (and GCCXML, for that matter):
> > >
> > > I am curious - what do you mean?
> >
> > * The Synopsis pipeline API is what is exposed to users, who then select
> >   and customize Py++ code-generating processors, much as they now select
> >   processors to customize documentation extraction and formatting.
> >
> > * Py++ merely uses the Synopsis C++ parser, but without using the pipeline
> >   approach.
> >
> > * Synopsis uses alternate C++ parsers (such as GCCXML or Elsa) internally,
> >   and Py++ accesses them through the pipeline API as in the first use case.
> 
> I have a very different vision of the solution :-).
> 
> > >> What if Py++ itself used Synopsis' pipeline language (and thus,
> > >> scripting frontend),
> > >> to drive the introspection as well as the code generation ?
> > >
> > > Good C++ parser is critical for s-2-s translators, but this is not enough.
> > > pygccxml contains type traits - the functionality very similar to
> > > boost::type_traits.
> > > It is a must.
> >
> > I'm not sure what you are saying. Type analysis is part of a real C++ parser.
> > Are you saying type inspection needs to be accessible through the intermediate
> > representation(s) ? I fully agree. (And in fact the AST does provide some
> > information about types, though this is clearly something that needs to be worked
> > on.)
> 
> Providing information about types and types them self is not enough.
> The framework should also provide functions, which make easier to
> analyze types. For example pygccxml has next functions:
> 
> is_convertible( source, target )
> is_integral( some_type )
> 
> Thus the code of s-2-s translator is much smaller and more readable.
> You can see the full list of functions and source code here:
> 
> http://language-binding.net/pygccxml/apidocs/pygccxml.declarations.type_traits-module.html

That is template generation helper.

You are querying the compiler at a particular point in the source.
That is too stress out the scoping of those queries.
Between declarations and type, you the notion of binding.

Things that are not done,
- do we have template that will be created at run-time.
- can we ask about static member function.
- see nothing about friends
- see nothing about typename
- see nothing about specialization
- see nothing for using
- see nothing about mutable, explicit, thread, typedef
- kind of scope(block, try, catch, function-parameter, class, namespace,
                template-parameter, for)

> > > This is the subject I am working right now. I am constructing
> > > declarations tree ( AST ) from Synopsis and GCC-XML. From my
> > > experience till now, the trees are very very different. GCCXML
> > > provides much more information

if fact, it is the reverse
- provided attached files give predefined built-in functions which
  can be used by the back-end. Analyzing those nodes and marking
  the one that are used will collapse the file.
  This also include removing function types.
- actual synopsis parser generate all the nodes in body of function.

> > Can you elaborate ? I don't doubt what you are saying, I merely
> > hope that a concrete list of metadata may help us complete the
> > Synopsis AST. (Since the existing type analysis is rather rudimentary,
> > most metadata gets stored as strings, e.g. 'premodifiers', 'postmodifiers'),
> > so it's impossible to do a true query like 'is this a const member ?'
> 
> I attached few files: source code, information generated by gccxml and synposis.
> Even if you say that enumerators has all relevant information the
> trees are still diffrent:
> * Synopsis doesn't have "::" global namespace ( module )

it is call <global>

> * All built-ins are missing - in my case this is not important, but
> still should be noted.

well, that is implementation details
easily fix by calling predefined vector of those.