Re: Perlstorm #0040
[email protected] (Hugo) Sun, 24 Sep 2000 03:50:02 +0100
| Newsgroups | perl.perl6.language.regex |
|---|---|
| Message-ID | <[email protected]> |
In <[email protected]>, Richard Proctor writes : :TomCs perl storm has: : :> Figure out way to do :> :> /$e1 $e2/ :> :> safely, where $e1 might have '(foo) \1' in it. :> and $e2 might have '(bar) \1' in it. Those won't work. : :If e1 and e2 are qr// type things the answer might be to localise :the backref numbers in each qr// expression. : :If they are not qr//s it might still be possible to achieve if the expansion :of variables in regexes is done by the regex compiler it could recognise :this context and localise the backrefs. : :Any code like this is going to have real problem with $1 etc if used later, :use of assignment in a regex and named backrefs (RFC 112) would make this :a lot safer. I think it is reaonable to ask whether the current handling of qr{} subpatterns is correct: perl -wle '$a=qr/(a)\1/; $b=qr/(b).*\1/; /$a($b)/g and print join ":", $1, pos for "aabbac"' a:5 I'm tempted to suggest it isn't; that the paren count should be local to each qr{}, so that the above prints 'bb:4'. I think that most people currently construct their qr{} patterns as if they are going to be handled in isolation, without regard to the context in which they are embedded - why else do they override the embedder's flags if not to achieve that? The problem then becomes: do we provide a mechansim to access the nested backreferences outside of the qr{} in which they were referenced, and if so what syntax do we offer to achieve that? I don't have an answer to the latter, which tempts me to answer 'no' to the former for all the wrong reasons. I suspect (and suggest) that complication is the only reason we don't currently have the behaviour I suggest the rest of the semantics warrant - that backreferences are localised within a qr(). I lie: the other reason qr{} currently doesn't behave like that is that when we interpolate a compiled regexp into a context that requires it be recompiled, we currently ignore the compiled form and act only on the original string. Perhaps this is also an insufficiently intelligent thing to do. Hugo