Re: symbol lookup and overload resolution

Stefan Seefeld wrote:
> 
> [...] there also is a low level API to manipulate the parse tree
> itself. [...] The big advantage of this approach is that code
> generation is not lossy, i.e. the changes are local, and everything
> else (inclusively formatting) is preserved.

It's good to hear that Synopsis already has those features.  Currently, 
CMT is only inspecting the AST and not modifying it.  That approach is 
working well enough for me now, as I prototype different CMT algorithms 
and get used to using Synopsis.  In effect, the only time that the AST 
changes is the *next* time that CMT runs, when it parses the source code 
that was modified by the *previous* CMT run.

Ultimately, that'll be too much of a limitation, and I'll have to start 
modifying the AST (and/or parse tree?), not just the corresponding 
source code.  But that's off in the future; I'm being more cautious with 
my initial efforts.

> FWIW, the parser itself (which is based on a fork of the OpenC++
> project from about 1999 or 2000) is extensible in that you can - to a
> certain extend - add new keywords and grammatical rules. The goal was
> precisely to do the kind of thing you want to do, i.e. support some
> form of metaprogramming.

Yes, I also looked at OpenC++ and OpenC++ Core, but I felt that Synopsis 
was in a more usable form -- both for my CMT project and for other 
projects that some of my co-workers want to do.  And we're also starting 
to use Synopsis to generate documentation for our delivered products 
(replacing Doxygen), so it makes sense to reuse Synopsis for several 
applications.

> I'm currently not sure whether or not to support that direction, as 
> with current scripting technologies it might be easier to place the 
> rules for the translation elsewhere, either inlined into comments or 
> completely outside the code (such as synopsis custom modules), and do
> the processing from scriptable processors.

Well, FWIW, here's my opinion.  I don't like the idea of adding new 
keywords and grammatical rules, and if anyone around here suggested it, 
then I'd definitely argue against it.  Doing those things means we'd be 
creating new languages that weren't C++.  Those new languages would be 
local to our project/group/department, and no other C++ compiler could 
read them.

Also, most of our people are not software professionals.  They're rocket 
scientists who have learned how to write code that's decent but not 
especially good.  (A few of us are software professionals, and we know 
how to design and write good software.  When we team up, the combination 
of their domain expertise and our software expertise works pretty well.) 
  So they only have up to a certain level of C++ knowledge.  Asking them 
to spend time exceeding that level -- learning C++ subtleties, mastering 
new not-quite-C++ languages, and so on -- would be a waste of their talents.

On the other time, it's pretty easy for them to learn how to use a tool 
that writes and audits some of their boilerplate code for them.  And at 
the end of the day, what they've produced is still understandable as 
straight C++.

> Hmm, I'd be curious to see how well the code generation works. While 
> the AST should be good enough for high level introspection such as
> manual generation, I have never thought that it was complete enough
> to be usable to actually regenerate the code it was produced from. As
> I said, generate new code is one thing, but regenerating the original
> one quite another...

So far, the code generation has been working very well.  Note that I'm 
not regenerating code from the AST.  Instead, I'm combining newly 
generated code with blocks of code from the original source files. 
Also, it helps that none of the concepts I'm modeling require me to muck 
around inside a function.  If I ever have to do that, then I agree I'd 
have a difficult job ahead of me.  But so far, so good...

> I'm generally very nervous about tools messing with hand-written
> code, because they always require some (often undocumented) special
> formatting to be able to work.

I feel the same way; I've been burned by such tools in the past.  That's 
one more reason why I'm being cautious as I develop this tool.

> One thing that you may be interested in is the code generation on the
> parse tree level. Lots of little pieces of code exist to support
> that but as I'v never used that feature myself until now, I haven't
> worked on it. May be, if we define clear goals, we can get it working
> quickly, with unit tests and all the other jazz.

That sounds like it could be really useful.  It seems the more I learn 
about Synopsis, the more I see how powerful it can be.  Thanks for all 
your help.

Rick
-- 
Richard M Kelly                             [email protected]
[PGP  =>  D5 C3 CC D2 B7 D0 A9 B0  D5 90 B2 55 5A 80 23 B6  FC AB 67 B4]