|Don't ask to ask, just ask|
/(\xFF\xD8 .*? \xFF\xD9)/Like a great friend of mine, you do talk a lot off track!
But your example is absolutely correct :-) This _is_ backtracking. However, it is exactly equivalent to
/(\xFF\xD8 .*? (?>\xFF\xD9))/
So, in a sense, it isn't _actually_ backtracking. Complicated backtracking would be when you cannot do that.
On to the future: one oft repeated mantra at the Monastery and elsewhere is that regexen are not well suited to parse HTML and XML, which is perfectly true. But under Perl 6 they will be so enhanced as to be promoted to "rules" which in turn, it is said, will be perfectly apt at implementing real parsers (although I'm not an expert, and not even a beginner, in parsing theory and I don't know which kind of parsers...) Ain't this a real-life problem?Indeed, parsers are real life problems. And I did realize that in PerlFAQ there is an entry:
Can I use Perl regular expressions to match balanced text?
That's "real life" enough.
You'll realize though, that when you're parsing (complicated) languages, you'll need to do things like error checking. So, in practice, either you'll need to make the regex un-humanly complex, or it still must contain "outlets" in form of function callbacks etc. in order to handle special conditions and the logic and semantics of the language that you're parsing.
I can see that the regex features mentioned above are useful, but I still don't feel very cozy about their beauty and simplicity. It _is_ however clear, that Perl will be at least as useful (and better) than traditional parsers (yet probably not quite as fast, unless you really understand internal implementation issues.
Thanks a lot for bringing up these thoughts.