<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div> 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.</div><div>I can now assemble ASTMatchers from s-expressions. </div><div>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.</div><div><br></div><div>Using the C++ DSL you would use:</div><div>fieldDecl(hasType(recordDecl(isDerivedFrom(recordDecl(hasName(“GCObject”)))))).bind(“all”)</div><div><br></div><div>In Common Lisp I would use:</div><div>(:bind :all (:field-decl (:has-type (:record-decl (:is-derived-from (:record-decl (:has-name "GCObject"))))))))</div><div><br></div><div><br></div><div>Question:</div><div><br></div><div>How do you get proficient at writing these matchers? I still struggle with it. </div><div>Do you have some way of looking at the AST dumps and then inverting them in your head into queries?</div><div>I’ll build something like the “clang-query” tool and practice.</div><div><br></div><div>I’m going to expose the refactoring classes/functions next and try some interactive source-to-source translation of C++ in Common Lisp.</div><div><br></div><div>Best,</div><div><br></div><div>.Chris.</div>
<br><div><div><br></div><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jan 9, 2014, at 5:41 PM, Samuel Benzaquen <<a href="mailto:sbenza@google.com">sbenza@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><div><div>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.</div>
<div>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.</div></div>
<div><br></div><div>What about this?</div><div>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.</div><div>Basically all matchers would be functions that return an object that has a name() method and a list of their arguments.<br>
</div><div>Then you can generate the C++ matcher string and use the C++ matcher parser to generate the actual matcher.</div><div>This way you only wrap a few [simple] functions from C++ and are shielded from the template metaprogramming craziness.</div>
<div>Hadn't thought this through, so it might be too simple to work =P.</div><div><br></div></div></div></div></blockquote><div><br></div></div></div></blockquote></div><br></body></html>