<div style="font-family: arial, helvetica, sans-serif"><font size="2">On Sun, Jun 17, 2012 at 9:46 PM, Evgeny Panasyuk <span dir="ltr"><<a href="mailto:evgeny.panasyuk@gmail.com" target="_blank">evgeny.panasyuk@gmail.com</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="im">
17.06.2012 22:44, Manuel Klimek wrote: <br>
<blockquote type="cite">
<div style="font-family:arial,helvetica,sans-serif"><font size="2">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> I see different
approaches to implement such kind of tool:<br>
1. Naive and straightforward way: just as external tool
to ASTMatchers, same method that I used in example
above. Such approach would result in some "knowledge"
duplication, i.e. for each predicate it would be
additional some code in predicate-generation tool.<br>
2. More complex way, but with some "knowledge" reuse
from ASTMatchers. That approach would require
re-describing predicates with some higher/another
abstraction, what would allow us to generate both
predicates and predicates-generation stuff from one
source of "knowledge". I am not sure if such approach
could be done in general, requires some research.</div>
</blockquote>
<div><br>
</div>
<div>My hunch is that for (2) the matchers would be
sufficiently different from what they are now, that it
would end up like (1) anyway - insert the obvious
disclaimer that I might be wrong etc etc here :)</div>
</div>
</font></div>
</blockquote></div>
Yes, (2) would require re-implementation of matchers in other terms.
But I think API of matchers will be not changed.<div class="im"><br>
<br>
<blockquote type="cite">
<div style="font-family:arial,helvetica,sans-serif"><font size="2">
<div class="gmail_quote">
<div>At least for a first step I think (1) is the way to go
- once we have more experience with how the stuff is used,
we can then try to figure out how to generalize it...</div>
</div>
</font></div>
</blockquote>
<br></div>
Yes, I fully agree. (1) is a good step to start with, at least for
prototype.<div class="im"><br>
<br>
<blockquote type="cite">
<div style="font-family:arial,helvetica,sans-serif"><font size="2">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<blockquote type="cite">
<div style="font-family:arial,helvetica,sans-serif"><font size="2">
<div class="gmail_quote">
<div>I don't know whether you're aware, but in
the tooling branch there's also a
proof-of-concept implementation for dynamic
matcher generation, and it might make sense
to base your stuff on that.</div>
</div>
</font></div>
</blockquote>
<br>
</div>
Are you talking about dynamic parseMatcher (as in
ast-query example)?<br>
</div>
</blockquote>
<div><br>
</div>
<div>Yep, that one...</div>
</div>
</font></div>
</blockquote>
<br></div>
Thank you for note.<div class="im"><br>
<br>
<blockquote type="cite">
<div style="font-family:arial,helvetica,sans-serif"><font size="2">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Or maybe about some
interactive (maybe gui) tool for building predicates? I
remember that Chandler mentioned about something similar
at <a href="http://www.youtube.com/watch?v=yuIOGfcOH0k&t=27m56s" target="_blank">http://www.youtube.com/watch?v=yuIOGfcOH0k&t=27m56s</a>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>Now we're talking the next step :) Yea, having a GUI
would be *great* (and just so we're clear: with GUI I mean
a web page :P)</div>
</div>
</font></div>
</blockquote>
<br></div>
And maybe AST database optimized for fast predicate matches :)<br></div></blockquote><div><br></div><div>For small projects this might be interesting - for us the question is how that would scale - we've found parsing the C++ code to be actually an interesting way to scale the AST, for the small price of needing up 3-4 seconds per TU (on average). Denormalizing the AST itself produces a huge amount of data, and denormalizing even more seems like a non-starter.</div>
<div><br></div><div>Thoughts?</div><div>/Manuel</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
Best Regards,<br>
Evgeny<br>
</div>
</blockquote></div><br></font></div>