Andrew Kuchling writes:
> If regex opcodes form part of the basic VM, would the main loop end up
> looking like the union of ceval.c and pypcre.c/_sre.c? The thought is
> too ghastly to contemplate, though a little part of me [*] would like
> to see it.
(perl guy speaking alert) The plan for perl6 is to implement the
regular expression engine as opcodes. We feel this would be cleaner
and faster than having the essentially separate module that we have
right now. I think our current perl5 project manager was the one who
said that we have no idea how inefficient our current RE engine is,
because it's been "optimized" to the point where it's impossible to
read.
The core loop would just be the usual opcode dispatch loop ("call the
function for the current operation, which returns the next
operation"). The only difference is that some of the opcodes would be
specific to RE matches. (I'm unclear on how much special logic RE
opcodes involve--it may be possible to implement REs with the
operations that regular language features like loops and tests
require).
Nat
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4