Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>I'm not entirely sure of that one--processing a full regex requires the
>perl interpreter, it's not all that modular. Though whether being able to
>yank out the RE engine and treat it as a standalone library is important
>enough to warrant being treated as a design goal or not is a separate
>issue. (I think so, as it also means I can treat it as a black box for the
>moment so there's less to try and stuff in my head at once)
We are way past that point in perl5 - having tried to use perl's regexps
in a non perl app you need perl there, not the interpreter perhaps
by bits of the tokenizer and of course SV *.
So to make it modular in perl6 yoiu have to re-write it, and I am will
Larry - lets make the main op-state machine handle those ops too.
That will help with need to special case regexps for signal despatch
etc.
>
>*) It makes the amount of mental space the core interpreter takes up smaller
But surely we are considering "expandable" intepreter already?
Adding regexp ops is just one such extension.
>*) It can make performance tradeoffs separately from the main perl engine
>*) We can probably snag the current perl 5 source without much change
I doubt that.
>*) The current RE engine's scared (or is that scarred?) me off enough that
>I'd as soon leave it to someone who's more tempermentally suited for such
>things.
>*) Treating regexes as non-atomic operations brings some serious threading
>issues into things.
Leaving them atomic does as well - I will switch threads as soon
as the regexp completes ...
--
Nick Ing-Simmons
