On Wed, Jan 30, 2002 at 08:37:30PM -0500, Bryan C. Warnock wrote:
> "But if you know they're going to be twenty times slower, why are you doing
> it?" Because we know / think / hope / pray / have been making sacrifices to
Tangential note: current benchmarking indicates that we're doing a lot
better than this. Two times slower is the right ballpark, and in cases
where we can tell the re compiler that we only need restricted
information out of the match, something like 20%. But that's based on
a probably nonrepresentative example and a duck walked within four
miles of my computer while I ran the test, so my numbers are about as
meaningful as the points on Whose Line Is It Anyway.
Somebody's been watching too much TV.
And on another tangent (tangential to this thread, not the list),
here's some motivation for an op-based regex engine: array matching.
if (@ARGV =~ regex('-o', '(', '.', ')')) { # pardon the syntax
$output = $1;
}
Maybe that would look better as regex/-o (.)/ ?
With an opcode-based engine, you get to reuse all the mechanics of
* + ? *? (?>) etc., and just add a new match_list_elt op. Which could
itself invoke a parrot subroutine so we're not restricted to element
equality matching as I implied in my above example.
I'm sure in Apoc 5 Larry's going to go way beyond that and embed full
parsers, not just regularish language matchers, but the above is
easier to grasp.
