On Thu, Aug 17, 2000 at 04:05:13PM -0700, Dave Storrs wrote:
> However, I think that if we're going to write this DFA at all, then the
> user SHOULD have the choice of using it for normal regex matchs, by
> specifying a specific flag (my choice was 'd'). Alternatively, the person
> should be able to use the regular regex engine for the line-end matchs if
> he wants expressiveness at the expense of speed.
Yeah. I'd think that making $/ a qr//'ed string would be sufficent. (IE if
$/ is a pure string, undef, or "", treat it like 5.6, if it's a qr//'ed
(with or without /f, make it a regex match with the desired engine)). Also, I
vote for the /f for Finite modifier -- the salient fact that we're telling
the user is that their regex must be gaurenteed to take finite time to match
against. (And for the F in DFA, and for Fast.)
I wonder, do we want the DFA matcher to save what matches the inside of
parens, or just be true or false? The former would allow it to be used in
more cases, but the second will make it even faster.
Oh, and I note that /d is defined for tr/// as somthing already (delete), so
/d for DFA could be confusing. (tr/// isn't an RE operator, but still.)
Do we want a language RFC on regex engines? Do we want some way of writing
a regex engine in pure perl that can be used normaly?
-=- James Mastros
