Re: symbol lookup and overload resolution

Stefan Seefeld wrote:
> 
> 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 welcome your thoughts and suggestions.

I call it the Concept Modeling Tool (CMT).  I've been wanting to build 
it for at least two years now, but lack of a C++ parser always stymied 
my efforts.  By building CMT on top of Synopsis, I've made pretty good 
progress in less than a month!  It's still in the prototype stage right 
now, but I hope to have it ready for use around here in the next few months.

You may already be familiar with this terminology: (1) A "concept" is a 
set of requirements that a software component, e.g. class C, may choose 
to meet.  (2) A component is a "model" of a concept if and only if it 
properly adheres to all of a concept's requirements.

CMT will let a developer do many things, but these are the big ones:

1. CMT can mark a component as claiming to model a particular concept.
2. CMT can query components to find out what claims they make.
3. CMT can automatically generate code to satisfy a component's claims.
4. CMT can audit code to be sure components really satisfy their claims.

Right now, my prototype works on components that are non-template 
classes, structs, and unions (a.k.a. CSUs), and it understands two 
concepts: Assignable and Comparable.  I've attached some descriptions 
from CMT's documentation, but they're basically like similarly named 
concepts from the STL.  Assignable handles the copy constructor and copy 
assignment operator; Comparable handles all the equality and inequality 
operators.  After examining the Synopsis-generated AST, CMT knows enough 
to automatically write the code for all those functions.  Also, it can 
use the AST's file/line markers to find any relevant, preexisting code 
wherever it may be and replace it with updated code.

By default, the code it generates is correct for most of the CSUs we 
write, but for special cases, CMT will also let you put more marks in 
the code.  For example, if class C uses data member m_cache to maintain 
a private cache, you could mark m_cache in the source code, and CMT will 
omit m_cache from the functions that it generates.  Or if the class has 
really special needs, you could mark some of its claims as "manual". 
That means, "Yes, this class really is a model of the XYZ concept, but 
don't muck around with those functions."

By the way, the source code marks are all in the comments (similar to 
Java tags), so it's still just regular C++ code to our compiler.

Once CMT is ready (and we have a corral full of supported concepts), our 
developers will be freed from writing many of the rote, mundane 
functions they currently do by hand.  And maintenance will be easier. 
If something changes -- let's say class C adds another data member -- 
the developer can just tell CMT to update the generated code.

That's what it does.  Here's how it does it.

First, CMT tells Synopsis to parse the source code files.  Then CMT 
examines the AST.  Suppose class C claims to be Assignable.  CMT uses 
the AST to determine class C's base classes and data members.  Then it 
generates class C's new copy constructor and copy assignment operator, 
and it inserts them into (its temporary copy of) the source code in the 
appropriate places.  Next it uses the AST to find out if class C already 
had those functions declared and/or defined anywhere; if so, CMT removes 
the obsolete stuff from the source code.  Finally, CMT overwrites the 
original source files with its updated copies.  If necessary, CMT will 
interact with the project's version control software to check out files 
that it needs to modify, etc.

In some cases, CMT won't have to generate code.  It'll simply have to 
collect and reorganize code.  In those cases, it'll just rearrange 
fragments of the source code files into the proper order.

As an aside, I'm building in several safety features to make sure that 
CMT doesn't irretrievably mess up the source code.  For example, it'll 
save copies of the original code in safe places, it'll support several 
levels of "undo", and if it's not sure about some preexisting code, 
it'll move that code to the bottom of the file instead of deleting it.

The beauty of CMT is, by since it relies on a full-featured parser to 
guide its analysis, developers won't have to format their code in any 
special ways, and they won't have to keep generated and handwritten code 
in separate files, etc.

One last thought: eventually CMT will handle things besides C++ code. 
As one example, we have certain requirements for the directories 
containing our source code, e.g. must follow certain naming conventions, 
must contain a Makefile, must contain a README file, must contain a test 
case subdirectory, and so on.  We could define a concept which embodies 
all of that and then let CMT help us manage our directory trees.

I welcome your thoughts and suggestions.  I know that, right now, I'm 
not using Synopsis to its full advantage or in the most effective ways. 
  But even now, Synopsis has been a great help to me, and I'm learning 
more about Synopsis as I build more and more of CMT.

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]

Assignable -- Defines objects which may be copied from and assigned to.

    The Assignable concept applies to a type.  It describes whether or
    not non-const objects of that type may be copied from and assigned
    to, and if so how.  This concept takes the following options in
    any order:

    [none|synthetic|public|protected|private] -- Specify which
    category of assignability is supported.  If more than one category
    is listed, then the last one listed takes precedence.  The default
    is "public".  Legal categories are:

        none -- Objects may not be copied from or assigned to.  No
        Assignable expressions are valid.

        synthetic -- Objects may be copied from and assigned to via a
        compiler-synthesized functions.  These Assignable expressions
        are valid:

            X(x)        X x(y);     X x = y;

        public, protected, private -- Objects may be copied from and
        assigned to via public, protected, or private functions,
        respectively.  The Assignable expressions listed above are
        valid.

    [explicit] -- tbd.
    
    [manual] -- Protect relevant code against automatic changes.  If
    this option is listed, CMT will not automatically change any code
    related to this concept.  The default is not to protect the code.

Comparable -- Defines objects which may be compared to other objects.
    
    The Comparable concept applies to a type.  It describes whether or
    not two objects of that type may be compared, and if so how.  This
    concept takes the following options in any order:

    [none|some|all] -- Specify which category of comparability is
    supported.  If more than one category is listed, then the last one
    listed takes precedence.  The default is "some".  Legal categories
    are:

        none -- No Comparable expressions are valid.

        some -- These Comparable expressions are valid:

            x == y      x != y

        all -- The Comparable expressions listed above are valid, as
        are these:
        
            x < y       x <= y      x > y       x >= y

    [manual] -- Protect relevant code against automatic changes.  If
    this option is listed, CMT will not automatically change any code
    related to this concept.  The default is not to protect the code.