Re: symbol lookup and overload resolution

Hi Richard,

Richard Kelly wrote:
> Stefan Seefeld wrote:
> 
>>
>> Does anybody see potential problems with such a separation between
>> symbol lookup and overload resolution (and probably more high level
>> analysis) ?
> 
> 
> Please pardon my ignorance.  Unfortunately, I probably don't currently 
> understand the topic well enough to spot any potential problems.  Can 
> you point me to a document or a site where I can read up on this?

I'm searching myself :-)
Concerning synopsis' own documentation, well, that still needs to be
written. The only existing documentation for the lowlevel stuff is
the manual that synopsis itself generates:

http://synopsis.fresco.org/docs/Manual/cxx/index.html

The issue here is that for overload resolution we have to perform
type analysis (type conversion, notably) which is quite heavy.
On the other hand, if we only need to find out whether a given
symbol is a type, a variable, etc., we don't need the above.

> Also, you said that the symbol lookup would return symbol sets of 
> possibly overloaded function names.  What would that look like to an 
> ordinary Synopsis user?  Is the symbol lookup something that our own 
> visitor classes would call, or is it something that's tucked away inside 
> Synopsis itself?  Basically, I'm trying to get a handle on what 
> interface my own software (built on top of Synopsis) will see.

That's an interesting question, particularly because that interface
is being redefined right now. Up to now Synopsis' interface was simply
the AST with an accent on A(bstract), as it is language independent
(to the extend this is possible), while not much syntax was exposed.

Now I'm cleaning up, refactoring, and enhancing the C++ parser
with the goal to make the lower level APIs (parse tree, symbol lookup,
etc.) publicly usable, too.
The first step into that direction was the creation of a new C++
library that programs can link to directly, i.e. without having to
use a python frontend.

However, these low level APIs aren't stable yet, so a lot of work
will go into bug fixing and cleanup, precisely to make them usable
publicly.

As I said, the first benefit will be that the parser can work
correctly in areas where it wasn't.

Before my redesign the parser created a parse tree that a 'Walker'
traversed to analyze it and translate into the AST (implemented in
python) that is the center-piece of synopsis. One problem with this
approach was that some of the analysis that should have been done
during the parsing to disambiguate certain syntactic constructs
were only done in a second pass (i.e. by the Walker).
Another problem is that the symbol lookup done via 'Environment'
and 'TypeInfo' classes was very incomplete.

Now the parser creates a parse tree as well as a symbol lookup table,
the latter already used by the parser itself.
Both can already be used in C++ (you may want to look into the applets
that are used in the unit testing, i.e. tests/OpenCxx/src/*.cc), and
I'm already pondering the possibility to expose both to python.
Once the new APIs are fully functional, most of the code now in
Synopsis/Parsers/Cxx/ will collapse and the only thing remaining
will be a Visitor that takes the parse tree and the symbol lookup table
and produces the AST.

>> With relatively little efford it will be possible to use the
>> redesigned parser for more advanced things that I will try to
>> integrate into the synopsis framework step by step, such as code
>> generation and various forms of code analysis beyond the documentation 
>> extraction that synopsis is currently used for.
> 
> 
> That's exciting news.  By the way, I've already been able to build a 
> (prototype) code analysis/generation tool on top of Synopsis.

That sounds great ! Can you describe what you are doing and how ?
Once I understand what you want to do I may be able to suggest
alternative approaches with the new APIs.

> I'm 
> looking forward to seeing these new capabilities, too.  I imagine 
> they'll make my prototype tool even more useful.

Hopefully !

Best regards,
		Stefan