2 ms·
There's the problem of regular expressions not dealing with matching parentheses, for one. That makes a lot of questions about code hard to express in a regexp,
by bazzargh 14y ago
There's the problem of regular expressions not dealing with matching parentheses, for one. That makes a lot of questions about code hard to express in a regexp, even something as simple as 'find foo(anything) + bar(anything)' is busted. False positives within strings are also an issue.
I did a code search thing, (which I don't claim is anything more than a hack) described over in this HN thread: http://news.ycombinator.com/item?id=4113348 http://news.ycombinator.com/item?id=4113348 but yes, the syntax wasn't quite 'a string', you'd type the code you're looking for with parts wildcarded, but parentheses in what you typed had to match.
- akkartik 14y agoThat's a good idea. Another use case occurred to me after I wrote my comment: to ignore keywords in comments. Sometimes that can be desirable. I keep going back lately to Rob Pike's idea that breaking files into lines is not the best approach (http://news.ycombinator.com/item?id=4111667 http://news.ycombinator.com/item?id=4111667). In that paper he proposes a regular expression for breaking up lines into structured content. But maybe there's another way. Like an ometa grammar? (http://tinlizzie.org/ometa http://tinlizzie.org/ometa) Anyways, just a few random thoughts.
- johnm 14y agoRegular expressions are the wrong tool for this job. For Krugle, we actually parsed the various languages so it actually knew the differences between e.g. definitions, invocations, comments, strings, etc. It affords the capabilities to do all sorts of cool queries and analyses.