about style: use possessive or atomic?

rsFalse has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: about style: use possessive or atomic? by LanX (Saint) on Aug 16, 2015 at 11:01 UTC
Isn't the second one a redundant way for writing `/($match)+/x` ? update No it's not, see my code further down. update thread overview Thread Tl;dr? After some confusion we identified a bug which was introduced with 5.20. See Re^8: about style: use possessive or atomic? (BUG!!!) Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :) Je suis Charlie!}	[reply] [d/l]
Re^2: about style: use possessive or atomic? by BrowserUk (Patriarch) on Aug 16, 2015 at 11:16 UTC
From perlre: `+ Match 1 or more times {n}+ Match exactly n times and give nothing back (redundant)` [download] I take the "redundant" annotation to mean that it is the same as: `+? Match 1 or more times, not greedily` [download] Though "not greedily" seems to conflict with "or more"? With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :) In the absence of evidence, opinion is indistinguishable from prejudice. I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!	[reply] [d/l] [select]
Re^3: about style: use possessive or atomic? by rsFalse (Chaplain) on Aug 16, 2015 at 11:38 UTC
`chomp( $match = <DATA> ); chomp( $_ = <DATA> ); for my $regex ( "($match){1}+", "($match)+", "($match)+?", ){ print qw(FAIL SUCCESS)[ !! m/\A $regex \z/x ], "\n" } __DATA__ (a\|b){2} bbab __OUTPUT__ FAIL SUCCESS SUCCESS` [download] Is it true that ($match){1}+ equals to simply $match?	[reply] [d/l]
Re^4: about style: use possessive or atomic? by Athanasius (Archbishop) on Aug 16, 2015 at 12:23 UTC
Re^5: about style: use possessive or atomic? by BrowserUk (Patriarch) on Aug 16, 2015 at 13:00 UTC
Some notes below your chosen depth have not been shown here
Re^4: about style: use possessive or atomic? by LanX (Saint) on Aug 16, 2015 at 12:42 UTC
Re^5: about style: use possessive or atomic? by rsFalse (Chaplain) on Aug 16, 2015 at 13:41 UTC
Some notes below your chosen depth have not been shown here
Re^3: about style: use possessive or atomic? by LanX (Saint) on Aug 16, 2015 at 11:33 UTC
I just ignored that the + is a possessive quantifier in this combination. ~~But its still redundant like the docs you cited say, backtracking wouldn't change without the plus.~~ ¹ (as far as I understand the docs with my pre coffee brain and without possibility to test on my mobile) Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :) Je suis Charlie!} ¹) no that's not true, see discussion further down!	[reply]
Re: about style: use possessive or atomic? by anonymized user 468275 (Curate) on Aug 16, 2015 at 17:39 UTC
Isn't all this a bit too cute for a Sunday? To put it another way, even if the incantation /expression{1}+/ yields something magical and unexpected, do you really want future maintainers to have a brain haemorrhage over it? (File instead under JAPH!!) Update: corrected spelling of haemorrhage One world, one people	[reply]
Re^2: about style: use possessive or atomic? by LanX (Saint) on Aug 16, 2015 at 20:09 UTC
> something magical and unexpected, Do you know what a atomic sub regex is? On the long run understanding backtracking is crucial when handling composed expressions. Especially when your scripts magically and unexpectedly deny terminating... But I agree that the OP might have provided more context. Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :) Je suis Charlie!}	[reply]
Re^3: about style: use possessive or atomic? by anonymized user 468275 (Curate) on Aug 16, 2015 at 21:01 UTC
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! One world, one people	[reply]

update

update thread overview