OK I see your point - there always needs to be a mechanism to control backtracking. And I have to confess some bias over that approach. At some point I started to favour designing lexers and parsers over trying to make the regex engine do too much for me. Not sure why other than the idea of being able to test atoms of code rather than send multiple atoms to something I can't easily test at the atomic level. However, 'horses for courses', although I think it remains true that although simplified use of regex might be slower on execution than getting the most out of the regex engine, there is one distinct advantages to my own approach: simpler regexes are more maintainable and parsers do need to be maintained. Often it is easier to explain theory using an extreme example: imagine the task is to read in any XML that might be thrown at you and convert it into a tree in Perl (CPAN not allowed). Programmer A is committed to making the regex engine do as much work as possible in designing this parser. Programmer B is the opposite, believing in lexers and parsers in pure perl with minimal use of regex. Who will produce the best results in reasonable time? Be honest!