Re: A bug in string.gmatch and string.gsub?

[Dirk Laurie <dirk.laurie@...>]

2013/4/30 TNHarris <telliamed@whoopdedo.org>:

> Yes, I'm was pointing out that if you're going to apply the principle of least
> surprise with respect to how regular expressions behave in other languages,
> the majority opinion seems to be with Perl which Lua follows. I also checked
> Node.JS and Ruby and they're the same.

Not how regular expression behave, how iterated search/replace behaves.
The distinction is very clear in LPEG: iterated search/replace might loop
infinitely, thus it is not allowed if the pattern can match empty strings.
The Perl manual argues that "long experience has shown that many
programming tasks may be significantly simplified by using repeated
subexpressions that may match zero-length substrings" and therefore
"Perl allows such constructs, _by forcefully breaking the infinite loop._"

The Perl way is motivated by one consideration only: to avoid an infinite
loop when zero-length matches are possible.

When it comes to choosing between Perl and Python as a model, on the
basis of what is more intuitive and natural, I'd go for Python 99% of the time.

Dirk

-----

sub e {
    $D =~ s/(.*)U$/U$1/;
    $D =~ s/U(.)/$1U/;
    $D =~ s/(.*)V$/V$1/; $D =~ s/V(.)/$1V/;
    $D =~ s/(.*)V$/V$1/; $D =~ s/V(.)/$1V/;
    $D =~ s/(.*)([UV].*[UV])(.*)/$3$2$1/;
    $c=&v(53);
    $D =~ s/(.{$c})(.*)(.)/$2$1$3/;
    if ($k) {
	$D =~ s/(.{$k})(.*)(.)/$2$1$3/;
	return;
    }
    $c=&v(&v(0));
    $c>52?&e:$c;
}