Robert Mathews wrote:
>
> > James Mastros wrote:
> > > [/f for fast DFA regexen]
> Jeremy Howard wrote:
> > The choice of algorithms is a great idea, but why do we need a modifier?
> > Isn't it a pretty straightforward set of rules that allow us to decide if a
> > DFA matcher will work? It would be a lot nicer if Perl could just notice
> > that the regex could be handled by its DFA matcher, all by itself.
>
> That would be nice, too, but a modifier would let you ensure that the
> DFA matcher was being used. You wouldn't have to guess whether a
> particular construct was DFA-able or not.
I'd rather have it figure it out by itself. It seems strange to be
telling the regex engine to be using a specific optimization. Though a
more general mechanism for requesting (forcing? suggesting?)
optimizations might make sense.
There would still be a use of a /f like flag, though -- treat all (...)
like (?:...). That would make the regex more likely to be DFA-able, and
is often what I want but I don't want to clutter up my regex with those
nasty ?:'s everywhere.
Even better would be to infer this from the lack of list assignment or
use of $1 etc. I'd be willing to accept having to explicitly use a $1
somewhere if I wanted $n to be accessible via eval"". Or even easier,
I'd forgo using eval"" if I wanted the optimization. This would require
$n to be lexical, which seems like a good thing anyway.
