Re: Re: software design clarification

Eric M. Hopper wrote:

>> C++ is particular in that a lot of that semantic analysis has to happen
>> at parse time, i.e. can't easily be deferred to latter stages.
>> However, that doesn't mean this information has to become part of the
>> parse tree. There are other representations that will be generated by
>> the parser.
> 
> *nod*  OK, that makes sense.  Representing it in the parse tree though
> makes doing things like refactoring editors much easier.  It would be
> highly amusing if someone could take your work on a C++ parser and turn
> it into a decent fancy refactoring editor like the Java folks have.

Indeed. I believe such use cases should be entirely within the scope of
Synopsis. All I'm saying is that the result of parsing source code will
be held in a set of representations, one of which is the parse tree.

The parse tree is really only a superstructure on top of a source buffer,
i.e. all leaf nodes of the tree point into actual source code. The way
the PTree as well as the Buffer collaborate make it possible to apply
local changes to the code, and then write it out again, leaving all
unchanged code intact, preserving everything, down to formatting.

There is no need to hook up the result of semantic analysis with the parse
tree, as not everybody may need it.

> Or maybe even something more bizarre like Xerblin:
> http://www.geocities.com/rogue_pedro/xerblin/  (The page may be
> out-of-date but it has better information than the page that isn't.)
> 
> I suppose they could just transform your parse tree themselves though if
> that's what they wanted.  There is a lot of trickiness in how C++ does
> symbol lookups though that might be really helpful to have tucked away
> somewhere.

Yes indeed, and it will definitely be available in a separate representation
(since the parser needs to do that work anyway). All I'm saying is that it
shouldn't be an integral part of the parse tree, for modularity.

For example, imagine a parse tree together with a dictionary mapping
parse tree nodes to declarators (the latter should become part of the
symbol table representation). That's all that is required in order to
traverse the parse tree, identifying connections from variable / type name
uses to their declaration.

However, I'd like to take this occasion to point out that the symbol table
isn't complete yet, and that I'd would very much appreciate any help in that
work.

Regards,
		Stefan

-- 

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