I have started wondering about the feasibility of replacing perl's regex engine with PCRE. The regex engine is supposedly pluggable already, but it looks as though plugging in a completely different regex engine would still be non-trivial. Any thoughts?
Now that gave me a good chuckle! (Score:2, Funny)
Perl 5.12
:)
I realize that you're serious, but it's funny anyhow...
-matt
Non default replacement (Score:1)
Just a thought. And secondly, what are the benchmarks like?
Re:Non default replacement (Score:1)
Doing it lexically would be trickier, because you'd have to either add a new set of OPs for the PCRE versions, or at least a flag for the existing ones. I was thinking it would be more along the lines of
use re 'debug';(which is to say, not lexically scoped).The first stage is to write a simple XS interface to PCRE, and then we can do some sensible benchmarks as well.
Named backreferencing. (Score:1)
You mention:
.. while talking about compositionality. Has anyone looked at implementing this in either the Perl5 engine or PCRE? Is anyone planning to? I'd like to have a crack at it, but it'll probably take a long time and be horrifically messy; though I've studied Kleene Alge
$a="printf.net"; Chris Ball | chris@void.$a | www.$a | finger: chris@$a
Implementing re::pcre (Score:2)
REGEXP*. For instance, many of the regexp magic variables ($+and the like) dive into theREGEXP*structure directly. That may not be too much of a problem, since you can useoptimize.pmto dike out thoseGVSVs and replace them with calls to a function in there::pcrelibrary.So other than that, it ought to be pretty plain sailing. If you're goi