At 11:24 AM 6/4/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Are you speaking of the nodes in regnode.h? I hadn't considered them as
>: regular perl opcodes--I figured they'd stay internal to the regex engine so
>: we could keep it reasonably modular.
>
>I don't think that's a terribly strong argument--one could justify any
>number of unfortunate architectural distinctions on the basis of
>modularity.
Yeah I know. I mean, look at how those darned bricks have held back
architecture all these years! :-P
>Plus, I'd argue you can still retain modularity of your
>code while unifying implementational philosophy.
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)
>It seems to me that the main reason for not considering such a
>unification is that We've Never Done It That Way Before. It's as if
>regular expressions have always been second-class programs, so they'll
>always be second-class programs, world without end, amen, amen.
No, not really. The big reasons I wasn't planning on unification are:
*) It makes the amount of mental space the core interpreter takes up smaller
*) It can make performance tradeoffs separately from the main perl engine
*) We can probably snag the current perl 5 source without much change
*) 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.
>The fact that Perl 5's regex engine is a royal pain to deal with should
>be a warning to us.
I can think of a couple of reasons that the current engine's a royal pain,
and they don't have much to do with it as a separate entity...
>Much of the pain of dealing with the regex engine in Perl 5 has to do
>with allocation of opcodes and temporary values in a non-standard
>fashion, and dealing with the resultant non-reentrancy on an ad hoc
>basis. We've already tried that experiment, and it sucks. I don't
>want to see the regex engine get swept back under the complexity carpet
>for Perl 6.
Yeah, but those are mostly issues with the implementation, not with the
separation.
>That's a scenario I'd love to avoid. And if we can manage to store
>regex opcodes and state using mechanisms similar to ordinary opcodes,
>maybe we'll not fall back into the situation where the regex engine is
>understood by only three people, plus or minus four.
While I'm not sure I agree with it, if that's what you want, then that's
what we'll do. Threading will complicate this some, since we'll need to
guarantee atomicity across multiple opcodes, something I'd not planned on
doing.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
