<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 5, 2012 at 3:08 PM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank" class="cremed">silvas@purdue.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Wed, Dec 5, 2012 at 12:09 PM, Samuel Benzaquen <<a href="mailto:sbenza@google.com" class="cremed">sbenza@google.com</a>> wrote:<br>

> Full C++ expression support for predicates. Values are going to be limited<br>
> to literals (eg. 1, “foo”). Expressions like 1+2 will not be parsed. Some<br>
> useful constants (like INT_MAX) might be available<br>
<br>
</div>This almost seems like an indictment of clang. Isn't the whole point<br>
of clang that we have a library which is capable of doing this?<br></blockquote><div><br></div><div style>True. You could use clang itself to parse it.</div><div style>For the proof-of-concept having a simple parser seemed easier.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">It seems like the fundamental issue that the dynamic matchers are<br>

trying to address is the long iteration time required by recompile.<br></blockquote><div><br></div><div style>There are two use cases for the dynamic matchers:</div><div style> - Faster development time for someone creating matcher expressions for a specific purpose.</div>
<div style> - Generic services that accept arbitrary matchers at runtime. Eg. a grep-like tool that uses matchers instead of regex.</div><div style><br></div><div style>The latter was my main motivation for this work.</div>
<div style> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Effectively, the dynamic matcher infrastructure would then simply be<br>
special purpose compiler for a subset of C++ with hardcoded semantics<br>
just enough to support the ASTMatchers. That really seems like a<br>
band-aid.<br></blockquote><div><br></div><div style>I think you are referring to the parser here, which is the one that is limited to declarative matcher expressions.</div><div style>The rest of the library (variant type, registry, etc) allows runtime generation of arbitrary matchers. This can be used independently of the parser if the generation of the expression is done in some other way.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
There has been quite a bit of work around speeding up this iteration<br>
loop using clang. The big one I can think of is cling<br>
<<a href="http://root.cern.ch/drupal/content/cling" target="_blank" class="cremed">http://root.cern.ch/drupal/content/cling</a>>. There is also an IDE (I<br>
think intended for game development) which uses Clang+JIT to<br>
dynamically run and recompile programs (e.g. you can change a constant<br>
in the source which represents a color, and in real time the running<br>
program reflects this change). There is even the relatively<br>
unmaintained examples/clang-interpreter which, while being quite crude<br>
and not feature-complete, is a remarkably short proof of concept.<br></blockquote><div><br></div><div style>I'll look into JIT'n the matchers.</div><div style>It could be a simpler solution for the problem.<br><br>
</div><div style>_Sam</div></div></div></div></div>