[cfe-dev] Writing C++ refactoring tools in Common Lisp

[Christian Schafmeister]

 I managed to hack/rewrite parts of Registry.cpp, Registry.h, Marshaller.h and Diagnostics.h so that they work with Common Lisp Symbols and Conses.
I can now assemble ASTMatchers from s-expressions.   
I exposed the entire ASTMatcher interface in one go - so I can write any ASTMatcher using S-expressions that can be written with the C++ DSL.

Using the C++ DSL you would use:
fieldDecl(hasType(recordDecl(isDerivedFrom(recordDecl(hasName(“GCObject”)))))).bind(“all”)

In Common Lisp I would use:
(:bind :all (:field-decl (:has-type (:record-decl (:is-derived-from (:record-decl (:has-name "GCObject"))))))))


Question:

How do you get proficient at writing these matchers?   I still struggle with it.   
Do you have some way of looking at the AST dumps and then inverting them in your head into queries?
I’ll build something like the “clang-query” tool and practice.

I’m going to expose the refactoring classes/functions next and try some interactive source-to-source translation of C++ in Common Lisp.

Best,

.Chris.


> 
> On Jan 9, 2014, at 5:41 PM, Samuel Benzaquen <sbenza at google.com> wrote:
> 
>> 
>> Most of them are simple functions, but there are also a lot that are "polymorphic". That is, they return a proxy type that allows late binding of the real matcher type.
>> During the implementation of the dynamic matcher registry I changed all these polymorphic/adaptative types to provide extra type information that allowed the registry to instantiate all the required functions.
>> 
>> What about this?
>> Instead of wrapping the actual matchers the way it is done in C++, you could make meta matchers that really only know their name and their arguments.
>> Basically all matchers would be functions that return an object that has a name() method and a list of their arguments.
>> Then you can generate the C++ matcher string and use the C++ matcher parser to generate the actual matcher.
>> This way you only wrap a few [simple] functions from C++ and are shielded from the template metaprogramming craziness.
>> Hadn't thought this through, so it might be too simple to work =P.
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140113/1b6e82a7/attachment.html>