[Synopsis-devel] Re: software design clarification

[Stefan Seefeld]

Markus Elfring wrote:
> 
>> Yes, the parse tree is provided by the Synopsis::PTree API (C++),
>> while the AST is provided by the Synopsis.AST API (Python).
>>   
> 
> Can it be that you mean abstract semantic graph with your "AST"?
> http://en.wikipedia.org/wiki/Abstract_syntax_tree#External_links

Yes, the line is definitely blurry and I have been considering a name
change.

> Would you like to map the Python interface to C++ classes?
> The other conversion direction would be supported by the tool
> "Simplified Wrapper and Interface Generator"
> (http://www.swig.org/compare.html).

Synopsis at present provides some of its APIs in C++ and some in Python.
I have specific plans to reflect the C++ APIs to Python, using boost.python.
I'm less certain about the other direction, but there is nothing preventing
it from being done.

>> Not a class, but an object (a PTree::Node, representing the root node
>> of the tree).
>>   
> 
> I suggest to provide a higher level API for compilation units (source
> files) and project related attributes.

Synopsis already has a 'SourceFile' class (Python), which holds various
information. The Parse Tree just isn't hooked up to it yet.

>> Not sure what you mean by 'mapping' in this context. The source from
>> which the parse tree is built may or may not be dependent on platform-
>> specific details (system headers, say), and so will the parse tree.
>>   
> 
> Header files can be part of platform independent standard specifications.

Show me any standard specification that isn't platform-dependent. :-)

> The choice of an useable programming language can be a platform
> dependent aspect.

Right. But Synopsis is much less concerned about modeling than about
code analysis (i.e. just the reverse). All those things you keep
talking about can be supported in layers on top of Synopsis. At this
point I'm just afraid of loosing the focus ('feature creep'), as
implementing what Synopsis strives for is hard enough.

>> I still fail to see what you are aiming at. So far it sounds pretty
>> academic.
>>   
> 
> I would like to stress the distinction of logical design and physical
> implementation. I hope that open issues can be better clarified with UML
> sketches.

I very much doubt it. Feel free to submit diagrams to open issues if you
think they clarify things, though.

Thanks,
		Stefan

-- 

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